Как я верстаю сайты на Elementor PRO: правила, которые избавляют от хаоса и упрощают поддержку

Elementor позволяет собрать страницу буквально за несколько часов. Поставить контейнер, добавить заголовок, картинку, кнопку — и визуально всё работает.

Проблемы обычно начинаются позже.

Нужно поменять основной цвет сайта — оказывается, он вручную прописан в десятках виджетов.

Нужно увеличить отступы — на одной странице стоят padding, на другой margin, а на третьей вообще добавлен пустой контейнер.

Клиент поменял номер телефона — приходится искать его в шапке, подвале, странице контактов и нескольких всплывающих окнах.

А через полгода открываешь Elementor и видишь:

Container
Container
Container
Container
Image
Heading
Container…

И попробуй вспомни, что из этого что.

Поэтому для себя я использую определённые правила верстки на Elementor PRO. Они не являются официальным стандартом Elementor и не претендуют на единственно правильный способ разработки.

Это скорее мой рабочий стандарт, который позволяет делать сайты аккуратнее, быстрее вносить изменения и не превращать WordPress в конструктор из сотен случайных настроек.

Разберём его по пунктам.

1. Начинаю с дочерней темы

Даже если почти весь сайт собирается в Elementor, сначала устанавливаю дочернюю тему.

Например, если используется Hello Elementor, устанавливаю Hello Elementor Child.

Зачем?

Потому что рано или поздно почти на любом нормальном проекте появляется собственный код:

дополнительные CSS-стили;
JavaScript;
PHP-функции;
переопределение шаблонов;
свои хуки WordPress;
изменения WooCommerce.

Конечно, часть этого можно разместить через Elementor Custom Code или плагины для сниппетов.

Но код, который относится непосредственно к проекту, мне удобнее хранить в дочерней теме.

Главное преимущество — изменения не пропадут после обновления основной темы.

Схема простая:

основная тема обновляется → дочерняя тема остаётся нетронутой.

Поэтому все свои изменения, относящиеся к теме сайта, стараюсь держать в child theme.

2. До верстки настраиваю глобальные стили

Одна из распространённых ошибок — сначала сверстать несколько страниц, а потом начинать разбираться со шрифтами и цветами.

Делаю наоборот.

До основной верстки определяю:

основной шрифт;
шрифт заголовков, если он отличается;
размеры H1, H2, H3;
основной цвет текста;
акцентный цвет;
дополнительные цвета;
цвета фона;
стили кнопок;
стандартные отступы.

И переношу всё это в глобальные настройки Elementor.

Вместо того чтобы в двадцати кнопках прописывать один и тот же HEX-код, назначаю им глобальный цвет.

Например, сейчас акцентный цвет сайта синий.

Через несколько месяцев заказчик решает заменить его на зелёный.

Если всё сделано через глобальные настройки, меняю один цвет — и он изменяется на всех элементах, где используется.

То же самое со шрифтами.

Это простая дизайн-система, которая полезна даже на небольшом сайте из пяти страниц.

3. Не прописываю одни и те же цвета вручную

Это продолжение предыдущего пункта.

Если цвет уже есть в глобальной палитре Elementor, использую именно его.

В собственном CSS также можно обращаться к глобальным переменным Elementor:

var(--e-global-color-accent)

Почему это важно?

Потому что иначе появляются две независимые системы.

Часть сайта управляется через Elementor, а часть — через CSS с вручную прописанными HEX-кодами.

Поменяли фирменный цвет — половина сайта изменилась, половина осталась старой.

На небольшом лендинге это ещё можно быстро исправить.

На сайте из 50–100 страниц начинаются суровые трудности.

4. Шрифты стараюсь загружать локально

Google Fonts удобно использовать прямо из Elementor.

Но предпочитаю локальную загрузку.

То есть файлы шрифтов находятся непосредственно на сервере сайта, а браузеру не приходится обращаться за ними к стороннему сервису.

Плюсов несколько:

меньше внешних зависимостей;
проще контролировать загрузку;
меньше сторонних запросов;
меньше вопросов, связанных с передачей данных сторонним сервисам.

Если используются Google Fonts через Elementor, проверяю настройку локальной загрузки отдельно.

Не рассчитываю на то, что Elementor автоматически настроил всё так, как нужно конкретному проекту.

5. Иконки — по возможности SVG

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

SVG хорошо масштабируется, не становится мыльным на экранах с высокой плотностью пикселей и удобно стилизуется.

Моё правило простое:

есть нормальный SVG — использую SVG.

При этом загружать случайные SVG-файлы из неизвестных источников на WordPress не стоит. Это формат, внутри которого может находиться код, поэтому источник файла должен быть доверенным.

Если использую Font Awesome через Elementor, также предпочитаю вывод иконок в SVG.

6. CSS храню там, где ему логично находиться

У меня простое правило.

Стиль используется на всём сайте

Пишу его в style.css дочерней темы.

Стиль относится только к одной странице

Можно использовать CSS конкретной страницы Elementor.

Стиль относится к шаблону

Например, шаблону записи или архива из Theme Builder — можно хранить его вместе с этим шаблоном, если так код проще поддерживать.

Главная идея здесь даже не в конкретном месте хранения.

Главное — не разбрасывать одинаковый CSS по десяткам элементов.

Плохой вариант:

карточка №1 → свой CSS;
карточка №2 → такой же CSS;
карточка №3 → ещё одна копия.

Хороший вариант:

один класс → одно правило CSS → используется всеми карточками.

7. Использую повторно применяемые CSS-классы

Например, в проектах можно завести класс для стандартных горизонтальных отступов секции.

У меня таким служебным классом может быть cp.

Тогда вместо ручной настройки одинаковых отступов у каждой секции используется одна система.

Но название здесь совершенно не принципиально.

Можно сделать:

section-padding

content-padding

container-main

Главное — чтобы разработчик понимал назначение класса через несколько месяцев.

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

Лучше:

service-card

чем:

blue-box

Потому что завтра карточка станет белой — и название blue-box внезапно потеряет смысл.

8. Не дублирую CSS внутри повторяющихся карточек

Особенно это важно для динамических списков: услуг, проектов, статей, сотрудников и других повторяющихся элементов.

Если карточка выводится 50 раз, не нужно привязывать оформление отдельно к каждой её копии.

Стили повторяющихся компонентов держу централизованно.

Например:

.project-card

.service-card

.team-card

И уже от этих классов строится оформление.

Так гораздо проще изменить дизайн сразу у всех элементов.

9. С изображениями работаю до загрузки в WordPress

Загружать фотографию размером 6000×4000 пикселей ради блока шириной 600 пикселей — плохая привычка.

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

Перед загрузкой обычно проверяю:

реальные размеры изображения;
вес файла;
нужен ли прозрачный фон;
можно ли использовать WebP;
можно ли использовать SVG.

Для обычных фотографий чаще всего использую WebP.

Для векторной графики — SVG.

Для растровой графики с прозрачностью выбираю подходящий формат исходя из качества и итогового веса.

Не стоит превращать это в правило вида «WebP всегда, PNG никогда».

Нужно смотреть на конкретный файл.

Главная задача простая:

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

10. Файлам даю нормальные имена

Вместо:

изображение (17) финал финал2.webp

использую что-нибудь вроде:

service-design.webp

hero-bg.webp

footer-bg.webp

Для логотипа:

logo.svg

Это кажется мелочью, пока в медиатеке находится 20 файлов.

Когда их становится 500, нормальные имена очень помогают.

Разработчику и контент-менеджеру гораздо проще понять назначение:

hero-bg

чем:

img_847593.webp

11. Не использую заголовки H1–H6 ради размера текста

У HTML-заголовков есть смысл.

H1, H2, H3 — это не просто «большой», «средний» и «маленький текст».

Они описывают структуру документа.

Например:

H1 — основная тема страницы.

H2 — крупный раздел.

H3 — подраздел внутри H2.

Поэтому если мне просто нужен текст размером 32 пикселя, это ещё не повод делать его H2.

Размер задаётся стилями.

HTML-тег выбирается исходя из смысла.

12. На практике оставляю один H1

На обычных коммерческих сайтах придерживаюсь простой и понятной структуры:

одна страница → один основной H1.

Например:

H1 — Разработка сайтов на WordPress

H2 — Какие сайты разрабатываю

H2 — Этапы работы

H2 — Стоимость

H2 — Частые вопросы

Так структура понятна и человеку, который редактирует сайт, и поисковым системам, и скринридерам.

13. Не вставляю H-теги везде подряд

Не использую заголовочный тег только ради внешнего вида.

Если элемент действительно является заголовком раздела — использую подходящий H-тег.

Если это просто визуально выделенная надпись, подпись, пункт интерфейса или вспомогательный текст — использую обычный HTML-тег и задаю нужный размер через CSS.

Сначала семантика.

Потом внешний вид.

14. Карточки статей оформляю как отдельные сущности

Для карточек блога логично использовать HTML-тег:

<article>

Потому что каждая карточка представляет самостоятельный материал.

А заголовок статьи внутри карточки получает H2 или H3 — в зависимости от структуры конкретной страницы.

Не существует правила «в карточке всегда H3».

Если карточки находятся непосредственно под H1, логичным может быть H2.

Если они находятся внутри раздела H2 — тогда H3.

Снова смотрим не на размер текста, а на структуру страницы.

15. Никогда не оставляю висячие предлоги

Это небольшая деталь, которая сильно влияет на восприятие текста, особенно в крупных заголовках.

Например, мне не нравится такой перенос:

Разработка сайтов на
WordPress

Короткий предлог на остаётся в конце предыдущей строки и визуально выглядит оторванным от слова, к которому относится.

Поэтому висячие предлоги и союзы на сайтах не оставляю.

Для заголовков можно использовать CSS:

text-wrap: balance;

balance старается более равномерно распределить текст между строками и часто делает заголовки визуально аккуратнее.

Но balance — это именно балансировка строк. Он не гарантирует, что короткий предлог никогда не окажется отдельно.

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

Он автоматически связывает короткие предлоги и союзы со следующим словом неразрывным пробелом.

Например:

в компании

на сайте

с клиентом

и разработка

Тогда браузер воспринимает такую конструкцию как единое целое и не переносит предлог отдельно от следующего слова.

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

Особенно удобно на динамических сайтах, где контент потом добавляет сам заказчик.

16. Внутренние ссылки по возможности делаю динамическими

Хардкодить полный адрес:

https://site.ru/services/

в десятках шаблонов не всегда хорошая идея.

Особенно когда:

сайт разрабатывается сначала на тестовом домене;
потом переносится на основной;
меняется структура;
один шаблон используется в разных местах.

Если Elementor, ACF или WordPress позволяют получить URL динамически — предпочитаю динамический вариант.

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

17. Телефон, email и другие контакты храню в одном месте

На сайтах с ACF PRO обычно создаю Options Page — отдельную страницу настроек сайта в административной панели WordPress.

Туда можно вынести:

телефон;
email;
адрес;
WhatsApp;
Telegram;
социальные сети;
часы работы;
реквизиты;
другие общие данные.

А в шапке, подвале, шаблонах страниц и всплывающих окнах эти значения выводятся динамически.

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

Поменял номер телефона в одном поле — он изменился во всех местах, где используется.

Не нужно вспоминать:

«А ещё вроде номер был на странице контактов, в подвале и в popup…»

18. Пустое поле не должно создавать пустой элемент

Например, у компании нет Telegram.

Тогда на сайте не должно оставаться:

иконка Telegram → пустая ссылка.

Или пустой промежуток между телефоном и email.

При динамическом выводе всегда стараюсь предусматривать условие:

поле заполнено → показываем элемент;
поле пустое → элемент не выводим.

Для этого можно использовать условия отображения Elementor, возможности используемых дополнений или небольшой собственный код.

Главное, чтобы структура страницы нормально работала и с заполненными, и с пустыми полями ACF.

19. Повторяющийся контент не собираю вручную страницами

Представим сайт компании, где есть 40 услуг.

Можно создать 40 отдельных страниц Elementor.

А потом вручную менять на каждой:

заголовок;
картинку;
описание;
цену;
галерею;
FAQ;
кнопку.

Работать будет.

Поддерживать — уже значительно веселее.

Если сущности имеют одинаковую структуру, создаю для них отдельный тип записей.

Например:

Услуги

И добавляю через ACF необходимые поля:

краткое описание;
изображение;
цена;
преимущества;
галерея;
этапы;
FAQ.

После этого создаётся один шаблон записи в Elementor Theme Builder.

Добавили новую услугу — просто заполнили поля.

Верстать новую страницу заново не нужно.

Тот же принцип использую для:

кейсов;
проектов;
портфолио;
сотрудников;
объектов;
автомобилей;
туров;
мероприятий;
других повторяющихся сущностей.

Для структуры таких сайтов в основном использую ACF/ACF PRO.

20. Поля ACF называю понятно

Технические имена полей предпочитаю писать латиницей.

Например:

service_price

hero_title

gallery

project_date

а не:

pole_1

text2

novoe_pole

Это снова кажется мелочью ровно до того момента, пока в проекте не становится 70 полей.

Через год service_price всё ещё понятно.

А вот назначение pole_17 придётся выяснять археологическими методами.

21. Большие наборы полей группирую

Если у записи много данных, делю их по вкладкам ACF.

Например:

Основное

заголовок;
описание;
изображение.

Характеристики

площадь;
материал;
срок;
стоимость.

Галерея

изображения.

Дополнительные настройки

дополнительные параметры.

Администратору сайта намного проще работать с такой формой.

Особенно если у записи несколько десятков полей.

22. Для изображений в ACF указываю рекомендуемый размер

Поле:

Изображение

не очень помогает контент-менеджеру.

Лучше:

Главное изображение

и примечание:

Рекомендуемый размер: 1600×900 px.

Человек сразу понимает, что именно загружать.

Меньше вопросов — меньше случайных вертикальных фотографий в горизонтальных блоках.

Для разных изображений можно указывать разные рекомендуемые пропорции непосредственно в инструкциях поля ACF.

23. ID полей форм должны быть уникальными

Особенно это важно, когда на странице несколько форм или JavaScript обращается к конкретному полю.

Не стоит создавать несколько элементов с одинаковым HTML id.

Для человека страница может выглядеть нормально, а JavaScript потом начнёт обращаться не к тому элементу.

Например:

phone

popup_phone

callback_phone

безопаснее, чем три одинаковых phone, если этим элементам действительно необходимы ID.

24. JavaScript не вставляю куда попало

Для небольшого локального кода можно использовать Elementor Custom Code.

Если JavaScript становится частью функциональности проекта, предпочитаю вынести его в отдельный:

custom.js

в дочерней теме.

И нормально подключить через WordPress.

Например:

function custom_js_css() {

    wp_register_script(
        'customjs',
        get_theme_file_uri('custom.js'),
        array('jquery'),
        filemtime(get_theme_file_path('custom.js')),
        true
    );

    wp_enqueue_script('customjs');
}

add_action('wp_enqueue_scripts', 'custom_js_css', 999);

filemtime() здесь особенно удобно во время разработки.

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

25. Не создаю контейнер просто потому, что могу

Контейнеры Elementor сильно упростили верстку.

Но появилась другая проблема: контейнеры иногда начинают создавать вообще для всего.

Получается примерно такое:

Контейнер
↳ Контейнер
　↳ Контейнер
　　↳ Контейнер
　　　↳ Заголовок

Иногда такая вложенность действительно нужна.

Но перед созданием очередного контейнера полезно задать вопрос:

а без него можно?

Чем проще DOM-структура, тем легче:

разобраться в верстке;
настроить адаптив;
писать CSS;
поддерживать сайт;
искать ошибку.

Поэтому лишняя вложенность — один из первых кандидатов на удаление.

26. Даю понятные названия контейнерам и виджетам в слоях Elementor

На сложной странице в панели слоёв легко получить:

Контейнер
Контейнер
Контейнер
Изображение
Заголовок
Контейнер
Контейнер
Кнопка.

На странице из нескольких десятков элементов ориентироваться в этом неудобно.

Поэтому основным контейнерам и важным элементам даю понятные названия на русском.

Например:

Шапка

Первый экран

Контент первого экрана

Заголовок первого экрана

Кнопки первого экрана

Изображение первого экрана

Преимущества

Сетка преимуществ

Услуги

Карточки услуг

О компании

Этапы работы

Кейсы

Форма заявки

Частые вопросы

Подвал

Название должно отвечать на простой вопрос:

что это за блок?

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

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

27. Для расположения блоков предпочитаю gap и padding

Основную геометрию контейнеров стараюсь строить через:

padding — внутренние отступы;
gap — расстояние между дочерними элементами.

margin тоже использую.

Он не запрещён и не является чем-то плохим.

Но если всю страницу строить из случайных:

margin-top: 73px

margin-bottom: 41px

отрицательных margin и индивидуальных поправок на каждом разрешении, поддерживать её становится тяжело.

Поэтому сначала смотрю, решается ли задача структурой контейнера, gap и padding.

И только потом использую внешний отступ там, где он действительно нужен.

28. Архивы пользовательских типов записей включаю осознанно

Создали тип записей «Проекты».

Нужна ли отдельная страница:

site.ru/projects/

Скорее всего, да.

Создали технический тип записей, элементы которого выводятся только внутри других страниц.

Нужен ли ему отдельный архив?

Возможно, нет.

Не стоит автоматически создавать страницы, которые потом:

пустуют;
дублируют другой контент;
случайно попадают в индекс;
не нужны посетителю.

У каждой архивной страницы должно быть назначение.

29. С микроразметкой не действую по принципу «чем больше, тем лучше»

Например, FAQ.

Если Elementor, SEO-плагин и дополнительный инструмент одновременно генерируют Schema.org для одного блока, можно получить дублирование разметки.

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

Сам FAQ при этом должен создаваться прежде всего потому, что он полезен посетителю.

Микроразметка — это дополнительный технический слой, а не причина создавать сам блок.

30. Использую готовые виджеты, когда они решают задачу без костылей

Например, нужно вывести:

иконка + заголовок + описание.

Можно собрать это тремя отдельными виджетами.

А можно использовать подходящий составной виджет, если его HTML и возможности устраивают.

Здесь нет универсального ответа.

Иногда отдельные элементы дают больше контроля.

Иногда один готовый виджет создаёт более аккуратную структуру.

Смотрю прежде всего на:

итоговый HTML;
адаптивность;
удобство редактирования;
количество лишних обёрток;
необходимость дополнительного CSS.

То есть не стараюсь собрать всё минимальным количеством виджетов любой ценой.

Выбираю вариант, который проще поддерживать.

31. Перед сдачей обязательно прохожу сайт как пользователь

Верстка закончена не тогда, когда макет похож на Figma.

Она закончена, когда сайт нормально работает.

Перед публикацией проверяю как минимум:

десктоп;
планшет;
мобильный;
меню;
формы;
кнопки;
ссылки;
номера телефонов;
всплывающие окна;
состояния hover;
длинные заголовки;
короткие заголовки;
изображения;
страницу 404;
консоль браузера;
динамические данные;
карточки;
шаблоны записей;
пустые поля ACF.

Отдельно полезно открыть сайт не авторизованным администратором, а в режиме инкогнито.

Иногда сайт для администратора и обычного посетителя ведёт себя по-разному из-за кеширования, условий отображения или оптимизации.

Главная мысль

Elementor PRO сам по себе не делает сайт ни хорошим, ни плохим.

Это инструмент.

Можно собрать на нём аккуратный сайт с понятной структурой, глобальной дизайн-системой, динамическими данными через ACF и удобным администрированием.

А можно получить сотню страниц, где каждая кнопка имеет собственный цвет, каждый блок — индивидуальные отступы, а номер телефона прописан вручную в 15 местах.

Внешне эти сайты первое время могут выглядеть одинаково.

Разница становится заметна после первой серьёзной правки.

Хорошо собранный сайт меняется за несколько минут.

Плохо собранный приходится буквально разбирать по частям.

Поэтому мой основной принцип при работе с Elementor простой:

не просто собрать страницу так, чтобы она выглядела как макет, а оставить после себя понятную систему, с которой можно нормально работать дальше.

Короткий чек-лист

Перед началом:

установлена дочерняя тема;
настроены глобальные цвета;
настроены глобальные шрифты;
проверена локальная загрузка шрифтов;
определены стандартные отступы.

Во время верстки:

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

Перед запуском:

проверен адаптив;
проверены формы;
проверены ссылки;
проверены динамические данные;
проверено поведение пустых полей;
нет ошибок JavaScript;
проверена микроразметка;
сайт протестирован как обычным пользователем, а не только из-под администратора.

На практике именно такие мелочи и отличают страницу, которую просто «собрали в Elementor», от сайта, который будет удобно развивать несколько лет.