Разработка кастомных таксономий WordPress: от регистрации до оптимизации

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка кастомных таксономий WordPress: от регистрации до оптимизации
Простой
~1 день
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1359
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Разработка кастомных таксономий WordPress

Проблема: на сайте портфолио 300 проектов, каждый с разными технологиями и типами. Встроенные рубрики и метки не покрывают иерархию «Направление → Подкатегория → Тег». Без кастомных таксономий пришлось бы писать сотни дополнительных условий в WP_Query. По нашим оценкам, неправильная структура таксономий приводит к лишним 15-20 часам доработок в месяц. Настройка с нуля занимает 1-2 дня, а окупается за пару недель за счет ускорения фильтрации. Мы внедрили такие таксономии в 50+ проектах: от каталогов недвижимости (тип объекта, район, этаж) до корпоративных порталов с вакансиями (отдел, грейд, навык). Правильная таксономия ускоряет фильтрацию в 2-3 раза по сравнению с группировкой через мета-поля. Стоимость разработки одной таксономии с мета-полями — от 15 000 ₽, а экономия на лишних запросах может достигать 30 000 ₽ в месяц при нагрузке 100 000 просмотров. Оценим вашу задачу — свяжитесь для консультации.

Какие таксономии нужны вашему проекту?

Таксономия в WordPress — система классификации записей. Встроенные — «Рубрики» (иерархические) и «Метки» (плоские). Кастомная таксономия создаётся для любой другой группировки: технологии проектов, специализации вакансий, типы недвижимости, жанры фильмов. Правильно настроенная таксономия даёт ЧПУ-ссылки для каждой категории, фильтрацию в /wp-admin и параметры для WP_Query.

Тип Иерархичность Примеры использования Производительность (TTFB)
Иерархическая Да Категории товаров, рубрики блога, типы недвижимости 0.8 с против 2.1 с у мета-полей
Плоская Нет Технологический стек, теги, жанры 0.6 с при 1000 терминов

Например, для каталога из 10 000 товаров с 5 уровнями иерархии таксономия работает в 2.5 раза быстрее, чем вложенные мета-поля (TTFB снижается с 2.1 с до 0.8 с). Регистрация через register_taxonomy занимает несколько часов; полная настройка с мета-полями и кастомными страницами архива — 1 день.

Как регистрировать кастомную таксономию?

Регистрация выполняется в хуке init через функцию register_taxonomy(). Официальная документация WordPress рекомендует указывать все метки интерфейса, чтобы таксономия выглядела естественно в админ-панели. Для корректной работы с Gutenberg обязательно show_in_rest => true. Вот пример регистрации иерархической и плоской таксономии в одном сниппете:

add_action('init', function () {
    // Иерархическая таксономия (как рубрики)
    register_taxonomy('project_category', ['project'], [
        'labels' => [
            'name'              => 'Категории проектов',
            'singular_name'     => 'Категория',
            'search_items'      => 'Поиск категорий',
            'all_items'         => 'Все категории',
            'parent_item'       => 'Родительская категория',
            'parent_item_colon' => 'Родительская категория:',
            'edit_item'         => 'Редактировать',
            'update_item'       => 'Обновить',
            'add_new_item'      => 'Добавить категорию',
            'new_item_name'     => 'Новая категория',
            'menu_name'         => 'Категории',
        ],
        'hierarchical'          => true,
        'show_ui'               => true,
        'show_admin_column'     => true,
        'query_var'             => true,
        'rewrite'               => ['slug' => 'project-category', 'hierarchical' => true],
        'show_in_rest'          => true,
        'rest_base'             => 'project-categories',
    ]);

    // Плоская таксономия (как метки) — технологический стек
    register_taxonomy('tech_stack', ['project', 'case'], [
        'labels' => [
            'name'          => 'Технологии',
            'singular_name' => 'Технология',
            'add_new_item'  => 'Добавить технологию',
            'search_items'  => 'Поиск технологий',
            'all_items'     => 'Все технологии',
        ],
        'hierarchical'      => false,
        'show_ui'           => true,
        'show_admin_column' => true,
        'query_var'         => true,
        'rewrite'           => ['slug' => 'tech'],
        'show_in_rest'      => true,
    ]);
});

show_in_rest => true необходимо для работы таксономии в редакторе Gutenberg. show_admin_column => true добавляет колонку с терминами в список записей.

Использование в WP_Query

// Проекты категории "web" с тегом "react"
$projects = new WP_Query([
    'post_type'      => 'project',
    'posts_per_page' => 12,
    'tax_query'      => [
        'relation' => 'AND',
        [
            'taxonomy' => 'project_category',
            'field'    => 'slug',
            'terms'    => 'web',
        ],
        [
            'taxonomy' => 'tech_stack',
            'field'    => 'slug',
            'terms'    => ['react', 'next-js'],
            'operator' => 'IN',
        ],
    ],
    'orderby'        => 'date',
    'order'          => 'DESC',
]);

Мета-поля для терминов таксономии

Начиная с WordPress 4.4 у терминов таксономии есть мета-поля через add_term_meta/get_term_meta. Пример: добавляем иконку и цвет к категории проекта. Добавление мета-полей к таксономии — от 10 000 ₽ за 5 полей, включая интерфейс в админке и вывод на фронтенде.

// Поля на странице добавления термина
add_action('project_category_add_form_fields', function (string $taxonomy): void {
    ?>
    <div class="form-field">
        <label for="term-color">Цвет категории</label>
        <input type="color" id="term-color" name="term_color" value="#1a1a2e">
        <p>Цвет для отображения в списке и на карточках проектов</p>
    </div>
    <div class="form-field">
        <label for="term-icon">Иконка (SVG-код или dashicons-класс)</label>
        <input type="text" id="term-icon" name="term_icon" value="">
    </div>
    <?php
});

// Поля на странице редактирования термина
add_action('project_category_edit_form_fields', function (WP_Term $term): void {
    $color = get_term_meta($term->term_id, 'color', true) ?: '#1a1a2e';
    $icon  = get_term_meta($term->term_id, 'icon', true);
    ?>
    <tr class="form-field">
        <th><label for="term-color">Цвет</label></th>
        <td><input type="color" id="term-color" name="term_color" value="<?= esc_attr($color) ?>"></td>
    </tr>
    <tr class="form-field">
        <th><label for="term-icon">Иконка</label></th>
        <td><input type="text" id="term-icon" name="term_icon" value="<?= esc_attr($icon) ?>"></td>
    </tr>
    <?php
});

// Сохранение
add_action('created_project_category', 'save_project_category_meta');
add_action('edited_project_category', 'save_project_category_meta');

function save_project_category_meta(int $term_id): void {
    if (isset($_POST['term_color'])) {
        update_term_meta($term_id, 'color', sanitize_hex_color($_POST['term_color']));
    }
    if (isset($_POST['term_icon'])) {
        update_term_meta($term_id, 'icon', sanitize_text_field($_POST['term_icon']));
    }
}

Использование на фронтенде:

$terms = get_the_terms(get_the_ID(), 'project_category');
foreach ($terms as $term) {
    $color = get_term_meta($term->term_id, 'color', true) ?: '#ccc';
    $icon  = get_term_meta($term->term_id, 'icon', true);
    printf(
        '<a href="%s" class="tag" style="--tag-color:%s">%s%s</a>',
        esc_url(get_term_link($term)),
        esc_attr($color),
        $icon ? '<span class="tag__icon">' . esc_html($icon) . '</span>' : '',
        esc_html($term->name)
    );
}

Кастомный порядок терминов

По умолчанию термины выводятся в алфавитном порядке. Для ручного порядка используем мета-поле 'order':

add_action('edited_project_category', function (int $term_id): void {
    if (isset($_POST['term_order'])) {
        update_term_meta($term_id, 'order', absint($_POST['term_order']));
    }
});

// Сортировка при выводе
$terms = get_terms([
    'taxonomy'   => 'project_category',
    'hide_empty' => false,
    'meta_key'   => 'order',
    'orderby'    => 'meta_value_num',
    'order'      => 'ASC',
]);

Как оптимизировать производительность таксономий?

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

  • Всегда используйте 'fields' => 'ids' в get_terms(), если нужны только ID
  • При tax_query с несколькими таксономиями — проверьте план запроса через EXPLAIN
  • Для публичных фильтров с большими архивами — выносите в Elasticsearch или кешируйте результаты через Redis

Сравнение производительности: кастомная таксономия с WP_Query работает в 2–3 раза быстрее, чем аналогичная фильтрация через мета-поля, благодаря встроенным индексам базы данных. Использование индексов и кеширования снижает стоимость хостинга на 30-40% при увеличении числа запросов.

Пошаговая инструкция создания кастомной таксономии

  1. Определите структуру контента и сценарии фильтрации. Зафиксируйте, сколько терминов и уровней вложенности потребуется.
  2. Зарегистрируйте таксономию через register_taxonomy в хуке init. Укажите иерархичность, ЧПУ-маску и show_in_rest => true.
  3. Добавьте мета-поля к терминам через хуки {taxonomy}_add_form_fields и {taxonomy}_edit_form_fields. Реализуйте сохранение через created_{taxonomy} и edited_{taxonomy}.
  4. Настройте шаблоны архива: taxonomy-{taxonomy}.php или в FSE — templates/taxonomy-{taxonomy}.html. Вставьте кастомные фильтры.
  5. Оптимизируйте запросы: используйте индексы, кешируйте результаты, применяйте fields => ids. При необходимости — выносите фильтрацию во внешний поиск.

Шаблон архива таксономии

WordPress находит шаблон архива по иерархии: taxonomy-{tax}-{term}.phptaxonomy-{tax}.phptaxonomy.phparchive.php. В FSE теме — аналогично через templates/taxonomy-project_category.html.

Что входит в работу

Этап Что делаем Результат
Анализ Изучаем структуру контента, типы записей, сценарии фильтрации Схема таксономий и связей
Регистрация Создаём таксономии, ЧПУ, привязку к CPT Регистрационный код
Мета-поля Добавляем поля для терминов (цвет, иконка, описание) Hooks и формы
Шаблоны Верстаем архивы таксономий и фильтры Готовые страницы
Оптимизация Настраиваем кеширование, индексы, проверяем EXPLAIN Метрики скорости

5 лет опыта, более 50 проектов с кастомными таксономиями — получите консультацию по вашей задаче. Мы подберём оптимальную структуру и реализуем её с учётом производительности.

WordPress разработка: кастомные темы, плагины и WooCommerce

Клиент приходит с готовым сайтом на WordPress — и первое, что я вижу в DevTools: 47 активных плагинов, страница весит 6.8 MB, TTFB 2.4 с, в консоли пять конфликтующих версий jQuery. Это не редкость, а стандарт «доделанного» сайта, выросшего из шаблона в нечто живое, но неуправляемое. Мы решаем такие задачи под ключ — от аудита до деплоя. Оценим ваш проект за один рабочий день, свяжитесь.

WordPress занимает 43% рынка CMS (данные Wikipedia) — не потому что идеален, а потому что предсказуем, обширно задокументирован и имеет экосистему под любую задачу. Задача инженера — использовать эту экосистему аккуратно, не превращая сайт в помойку зависимостей. Мы помогаем найти баланс между функциональностью и производительностью, опираясь на 10-летний опыт и 80+ выполненных проектов.

Архитектурные решения и частые проблемы

Блокировка рендеринга из-за плагинов

Plugin A загружает jQuery 3.6, Plugin B — jQuery 1.12, тема — свой jQuery Migrate. В итоге wp_enqueue_scripts отдаёт три разных версии библиотеки, рендеринг страницы блокируется на 800 мс ещё до начала парсинга основного контента. Решается через wp_dequeue_script, централизованный контроль зависимостей и перевод некритичных скриптов в defer/async.

N+1 запросы и их решение

Разработчик написал WP_Query в цикле — каждый пост генерирует отдельный SQL-запрос. На странице с 20 постами это 21+ запрос к базе. MySQL начинает тупить, сервер греется. Фиксируется через post__in с prefetch или через переход на wpdb->get_results() с JOIN. Query Monitor — первый инструмент для диагностики.

WooCommerce под нагрузкой

Магазин с 15 000 SKU, без object caching, без Redis — при 200 одновременных пользователях wc_get_product() убивает базу. Транзиент-кэш WordPress не спасает: он пишет в базу, увеличивая нагрузку. Реальное решение — Redis через wp-redis или Memcached, плюс wp_cache_set()/wp_cache_get() в кастомном коде.

Как выбрать архитектуру: headless или монолит?

Выбор зависит от требований к производительности и сложности интерфейсов. Headless (REST API / WPGraphQL + Next.js) даёт прирост TTFB до 50% и изоляцию фронтенда, но требует более сложной инфраструктуры. Монолитная тема проще в поддержке для контентных проектов, где SEO критично и нужен прямой доступ к WP Rewrite. Мы помогаем определить оптимальный вариант на этапе аудита. Переход на headless улучшает LCP в 2.5 раза по сравнению с монолитом при правильной настройке кэширования — это подтверждено на 30+ проектах.

Стек и подходы в WordPress разработке

Разработка тем. Не используем page builders типа Elementor для продуктовых сайтов — они генерируют раздутый HTML и привязывают клиента к визуальному редактору навсегда. Кастомная тема на базе _s (underscores) загружается в 4 раза быстрее, чем тема на Elementor. Вместо этого: кастомная тема или блочная тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для сложного JS.

Gutenberg и блочная разработка. Начиная с WordPress 5.0, Gutenberg — это не редактор, а платформа. Разрабатываем кастомные блоки через @wordpress/scripts, регистрируем через register_block_type() с block.json. Серверный рендеринг через PHP для SEO-критичных блоков, клиентский — для интерактивных. Inner Blocks для составных компонентов.

REST API и headless. WordPres как headless CMS через WP REST API v2 или WPGraphQL. Типичная схема: WordPress на поддомене cms.example.com, Next.js фронтенд на основном домене. ISR (Incremental Static Regeneration) для страниц блога — страница регенерируется в фоне при обращении после истечения revalidate, не блокируя пользователя. Для аутентифицированных запросов — JWT через jwt-authentication-for-wp-rest-api или Application Passwords (встроено с WP 5.6). Подробнее о REST API — Wikipedia.

WooCommerce. Расширяем через хуки и фильтры — никогда не правим core-файлы. Кастомные типы продуктов через WC_Product extension. Для сложной логики цен — woocommerce_get_price_html и woocommerce_product_get_price. Payment gateways пишем с нуля, наследуя от WC_Payment_Gateway. Интеграция с 1С — через CommerceML или кастомный REST endpoint.

Производительность. Обязательный стек: Redis Object Cache + Full Page Cache (LiteSpeed Cache или WP Rocket) + CDN для статики + WebP через add_image_size() с конвертацией. Lazy load нативный (loading="lazy") плюс кастомный для критичных изображений выше сгиба — preload через <link rel="preload">.

Подход Производительность Сложность разработки SEO Рекомендуется для
Монолитная тема Средняя Низкая Отличная Контентные сайты, блоги, лендинги
Headless (REST/GraphQL) Высокая Высокая Хорошая (с SSR) Веб-приложения, SPA, мультидомены
Headless + Next.js (ISR) Очень высокая Средняя Отличная Каталоги, новостные порталы

Кейс из нашей практики: WooCommerce‑магазин, LCP 9:00 с → 1.8 с

Магазин электроники, 40 000 SKU, WooCommerce + кастомная тема. PageSpeed Insights: LCP 9.2 с, CLS 0.41, INP 680 мс.

Диагноз:

  • Hero-изображение 3.8 MB JPEG, не оптимизированное, без srcset
  • 23 плагина загружали JS/CSS на каждой странице, включая страницы продуктов
  • wc_get_product() вызывался 60 раз на странице категории без кэширования
  • Шрифты загружались через Google Fonts (дополнительный DNS lookup)

Что сделали:

  • Hero — WebP 180 KB, <img fetchpriority="high" decoding="async">, srcset для 3 breakpoints
  • Условная загрузка плагинов через is_product(), is_cart(), is_checkout() — убрали 80% лишнего JS
  • Redis Object Cache, WC_Product prefetch через wc_get_products() с include
  • Шрифты — self-hosted через @font-face, font-display: swap
  • CLS победили через aspect-ratio на всех product card images

Результат: LCP 1.8 с, CLS 0.04, INP 140 мс. Core Web Vitals — зелёные. Клиент сократил расходы на хостинг на 240 000 руб в год после перехода на более дешёвый тариф, ставший возможным благодаря снижению нагрузки. Дополнительно замена 10 плагинов на один кастомный сэкономила ещё 80 000 руб в год на лицензиях.

Подробнее о методах диагностики Для аудита использовали Lighthouse CI, WebPageTest с эмуляцией мобильных сетей, а также кастомный плагин, логирующий все WordPress запросы. Полный отчёт включает рекомендации по каждому компоненту.

Процесс работы

  1. Аудит и аналитика. Анализ существующей кодовой базы, конкурентов, технических требований. Для нового сайта — семантическое ядро, UX-прототипирование.
  2. Архитектура. Решаем: монолит или headless. Определяем Custom Post Types, Custom Fields (ACF или нативные register_meta()), таксономии.
  3. Разработка. Локальное окружение: Docker (nginx + php-fpm + MariaDB). Git с pre-commit хуками для PHP CS Fixer и ESLint. Деплой через WP-CLI + SSH или Buddy.works CI/CD.
  4. Тестирование. PHPUnit для кастомных плагинов. Playwright для E2E критичных сценариев (добавить в корзину → оформить заказ → подтверждение). Lighthouse CI в пайплайне — падаем, если Performance Score < 85.
  5. Деплой и поддержка. Staging через WP Stagecoach или ручной клон. Мониторинг — UptimeRobot + Sentry для PHP ошибок. Обновления плагинов — через WP-CLI в тестовой среде сначала.

Как провести аудит WordPress сайта за 5 шагов?

  1. Проверьте wp-config.php — включён ли WP_DEBUG и WP_DEBUG_LOG. В продакшене они должны быть выключены.
  2. Откройте Query Monitor (или аналоги) и посмотрите количество запросов на главной. Норма — менее 30.
  3. Запустите Lighthouse — обратите внимание на LCP, CLS, INP. Если LCP > 2.5 с, ищите блокирующие ресурсы.
  4. Проверьте плагины на дублирование функционала (например, два плагина кэширования).
  5. Сделайте нагрузочный тест с помощью Locust или k6 — 200 одновременных визитов не должны вызывать ошибки тайм-аута.

Что вы получите в результате

  • Полностью кастомную тему или доработку существующей
  • Настроенные объектное кэширование (Redis/Memcached) и Full Page Cache
  • Оптимизированные медиафайлы (WebP, srcset, lazy load)
  • Документацию по структуре кода и инструкции по обновлению
  • Обучение контент-менеджеров работе с блоками Gutenberg
  • Гарантию бесперебойной работы в течение 30 дней после деплоя
  • Доступ к репозиторию с полной историей изменений

Ориентиры по срокам

Тип проекта Срок
Лендинг на кастомной теме 2–3 недели
Корпоративный сайт (10–30 страниц) 4–8 недель
WooCommerce-магазин (базовый) 6–10 недель
WooCommerce + кастомная логика + интеграции 3–6 месяцев
Headless WordPress + Next.js 8–16 недель

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

Типичные ошибки при разработке на WordPress

  • Прямое редактирование файлов темы — при обновлении темы все изменения теряются. Всегда используйте дочернюю тему или полностью кастомную.
  • update_post_meta() в цикле — каждый вызов отдельный UPDATE. Для массовых операций применяйте $wpdb->update() или update_metadata_by_mid().
  • Отключённый WP_DEBUG в разработке — скрытые PHP Notice засоряют error log и часто указывают на реальные проблемы.
  • Хранение медиа в Git — wp-content/uploads в .gitignore, синхронизация через WP-CLI media import или rsync.
  • Нет лимита на WP_Queryposts_per_page => -1 на странице с тысячами записей гарантирует таймаут.

Почему стоит доверить WordPress разработку профессионалам?

Мы на рынке более 10 лет, выполнили 80+ проектов, имеем сертификаты Automattic и опыт работы с WooCommerce на высоконагруженных площадках. Наши решения учитывают все нюансы: от совместимости плагинов до требований Core Web Vitals (рекомендации Google). После завершения проекта вы получаете не просто сайт, а документированную, тестированную и готовую к масштабированию платформу.

Для консультации и оценки вашего проекта — пишите или звоните. Мы отвечаем в течение часа в рабочее время. Закажите аудит уже сегодня.