Разработка SEO-friendly WordPress-сайта на собственной теме

Поэтому в процессе разработки я отказалась от идеи строить проект вокруг универсального визуального конструктора. Вместо этого сделала собственную тему WordPress и вынесла специфические функции сайта в отдельные небольшие плагины.

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

Результат

• 1 — собственная тема WordPress
• 6+ — отдельных функциональных модулей
• 2 — сценария отправки форм
• 4 — технических элемента антиспам-защиты

Исходная задача

Для сайта SEO-специалиста мне были нужны достаточно специфические функции:

• отдельные страницы услуг;
• информационные статьи;
• полноценный раздел кейсов;
• возможность выводить дополнительный текст сразу после H1;
• автоматическое содержание длинных материалов;
• изображения и результаты для кейсов;
• формы заявки;
• мобильные быстрые контакты;
• управление Cookie и Яндекс.Метрикой;
• canonical, Open Graph и микроразметка;
• возможность постепенно добавлять новые функции без полной переделки темы.

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

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

Собственная тема WordPress вместо универсального конструктора

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

Собственная тема дала контроль над теми участками, которые действительно важны для дальнейшей SEO-работы:

• структурой шаблонов;
• последовательностью H1 и основного контента;
• местами вывода дополнительных блоков;
• HTML страниц;
• типами контента;
• подключаемыми CSS и JavaScript;
• внутренней навигацией;
• дальнейшим масштабированием.

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

SEO-блоки заложены непосредственно в архитектуру темы

Один из характерных примеров — область сразу после H1.

В шаблоне страницы H1 выводится сервером, после чего вызывается отдельный hook:

<h1><?php the_title(); ?></h1>
<?php do_action( '...h1', get_the_ID() ); ?>

За счёт этого дополнительный SEO-блок после H1 не приходится каждый раз вручную вставлять в редактор или искать заголовок на странице через JavaScript.

В самой теме предусмотрена штатная точка расширения.

Добавление ...h1 было отдельно зафиксировано в документации обновления темы, а после установки проверялись статья с TOC, текст после H1 и страница услуги.

Для меня это один из базовых принципов SEO-friendly разработки:

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

Вместо одного большого плагина — отдельные модули

Я не стала собирать все функции сайта в один большой самописный плагин.

На фронтенде проекта используются отдельные компоненты:

• ...h1;
• ...case-images;
• ...cookie-metrika;
• ...seo-forms;
• ...seo-mobile-contact;
• ...seo-toc.

У такого подхода есть практическое преимущество.

Если нужно изменить содержание статьи, я работаю только с TOC-модулем.

Если меняется логика формы — с плагином форм.

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

Получилась схема:

тема отвечает за каркас сайта → отдельный модуль отвечает за конкретную функцию.

При обновлении компонентов также сохранялись существующие option и meta keys, чтобы уже заполненные данные не приходилось переносить заново.

Автоматическое содержание длинных материалов

Для статей и кейсов используется отдельный TOC-модуль.

В HTML сайта подключаются стили ...seo-toc, а для якорей предусмотрен scroll-margin-top, чтобы при переходе по содержанию заголовок не перекрывался верхней частью интерфейса.

Практический смысл простой.

Вместо ручного создания:

• названия раздела;
• якоря;
• ссылки на него;
• отдельного обновления содержания после каждого изменения H2,

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

Это особенно удобно для длинных SEO-кейсов, аудитов и информационных статей.

Основной контент формируется сервером

Я не ставила задачу полностью отказаться от JavaScript.

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

Но основной текст страницы от JavaScript не зависит.

H1 и содержимое записи выводятся PHP-шаблоном WordPress через the_title() и the_content().

То есть принцип такой:

основная структура, заголовки и текст присутствуют в HTML-ответе сервера, а JavaScript дополняет интерфейс там, где он действительно нужен.

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

Кейсы вынесены в отдельный тип контента

Кейсы не смешиваются с обычными статьями.

У них другая задача и своя структура.

Статья отвечает на информационный вопрос.

Кейс должен показывать:

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

Поэтому в теме зарегистрирован отдельный тип записи ...case, а его архив работает в структуре /cases/. Это подтверждается регистрацией типа записи и реальными страницами кейсов.

Так раздел можно развивать независимо от блога.

Для кейсов могут быть собственные:

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

То есть это уже не просто рубрика статей, а отдельная часть информационной архитектуры сайта.

Готовые SEO-функции не переписывала без необходимости

При этом я не придерживалась принципа:

«всё на сайте должно быть самописным».

Стандартную SEO-инфраструктуру оставила профильному решению — Yoast SEO.

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

• canonical;
• Open Graph;
• WebPage;
• BreadcrumbList;
• WebSite;
• сущность автора или организации.

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

Это позволяет не тратить время на переписывание стандартных функций WordPress и SEO-плагина.

Формы вынесены в отдельный модуль

Формы реализованы отдельным компонентом ...seo-forms.

В текущем HTML предусмотрены два сценария отправки:

• обычный POST через wp-admin/admin-post.php;
• отправка через собственный REST endpoint .../v1/lead.

Также для формы задан отдельный endpoint .../v1/form-token.

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

Это особенно удобно для модальных и встроенных консультационных форм.

Антиспам без внешней CAPTCHA

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

Я не хотела заставлять посетителя решать CAPTCHA или подключать внешний виджет только ради базовой защиты.

В HTML формы присутствуют:

• WordPress nonce;
• время начала заполнения;
• подписанный временной маркер;
• два honeypot-поля: website_check и company_fax.

Все эти элементы невидимы обычному пользователю.

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

Я не включаю в кейс неподтверждённые детали внутренней серверной проверки — например конкретный rate limit или логику блокировки запроса. Здесь описано только то, что подтверждается текущим HTML формы.

Cookie и Яндекс.Метрика вынесены из темы

Аналитика и Cookie-согласие работают через отдельный модуль:

...cookie-metrika.

В HTML передаются:

• имя cookie согласия;
• срок хранения;
• ID Яндекс.Метрики.

Пользователю выводится отдельный баннер со ссылкой на политику конфиденциальности и кнопкой «Согласен».

Мне было важно не встраивать Метрику намертво в тему.

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

Мобильные контакты сделаны отдельным компонентом

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

В текущем HTML она содержит ссылку на Telegram и кнопку открытия формы проекта.

Эта функция вынесена в ...mobile-contact, поэтому мобильный блок можно дорабатывать независимо от основной темы и десктопной навигации.

Изображения и базовая производительность

При разработке я старалась не добавлять тяжёлые зависимости без необходимости.

В обычных блоках сайта изображения выводятся, в частности, с:

loading="lazy"

и:

decoding="async".

Это видно в HTML главной страницы.

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

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

Отдельно пришлось разобраться с техническим наследием домена

На домене обнаруживались старые URL вида:

/shop.php?...

/goods.php?...

которые не относятся к текущей версии сайта.

Для них в серверной конфигурации предусмотрен ответ:

410 Gone.

Одновременно были подготовлены правила:

• www → non-www;
• index.php, index.html, index.htm → главная;
• нормализация завершающего /.

Эту работу я рассматриваю отдельно от контента.

SEO нового сайта начинается не только с H1 и Title. Если домен имеет техническое наследие, сначала нужно привести в порядок URL и ответы сервера.

Что получилось в итоге

Главный результат этой разработки — не количество написанных PHP-файлов и не сам факт отказа от Elementor.

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

Архитектура сейчас выглядит примерно так:

WordPress

↓

собственная тема Victoria SEO

↓

отдельные типы контента

↓

небольшие функциональные модули

↓

Yoast для стандартной SEO-инфраструктуры

↓

собственные решения для специфичных задач проекта

На сайте уже используются отдельные модули для:

• текста после H1;
• изображений кейсов;
• Cookie и Метрики;
• форм;
• мобильных контактов;
• содержания длинных материалов.

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

Почему я считаю такой подход SEO-friendly

Не потому, что у сайта есть какой-то специальный «SEO-движок».

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

• где должен находиться H1;
• как выводить дополнительный текст после него;
• как разделять статьи и кейсы;
• как строить содержание длинного материала;
• как управлять canonical и метаданными;
• как не зависеть от JavaScript для основного текста;
• как добавлять новую функцию без полной переделки темы;
• как контролировать старые URL;
• как подключать аналитику отдельно;
• как не ставить тяжёлый универсальный плагин ради одной небольшой функции.

Victoria SEO стал для меня не только собственным сайтом, но и рабочей площадкой для подхода, который можно применять в клиентских WordPress-проектах.

Итог

При разработке я сознательно ушла от схемы:

сначала собрать сайт → потом оптимизировать его под SEO.

Вместо этого использовала другой порядок:

определить структуру и задачи → подготовить шаблоны → заложить SEO-точки расширения → подключать отдельные функции по мере необходимости.

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

Для собственного SEO-проекта это оказалось важнее количества готовых виджетов в панели редактора.