Відкритий квиток 
+373 79 600002 
Telegram Онлайн-чат 
Часті запитання 
Українська
English 
Русский 
Română 
Deutsch 
Français 
Türkçe 
Español 
Português 
български 
Polski 
Indonesia 
中文 (中国) 
АдміністраціяWordPress Батьківські Сторінки: Повний Технічний Посібник з Ієрархічної Структури Сторінок
У WordPress Батьківська сторінка — це сторінка верхнього рівня, яка виступає кореневим вузлом у ієрархічних відносинах, з однією або кількома Дочірніми сторінками, вкладеними під неї. Ця структура керує успадкуванням URL-слагів, відображенням навігації, вибором шаблонів і тим, як пошукові системи інтерпретують тематичний авторитет у пов’язаних кластерах контенту.
Коли ви призначаєте батьківську сторінку, WordPress зберігає зв’язок у таблиці wp_posts через стовпець post_parent. Постійне посилання дочірньої сторінки потім формується шляхом додавання слагу батьківської сторінки на початок, створюючи вкладений URL-шлях, наприклад /services/web-design/. Це не просто косметична зміна — вона безпосередньо впливає на глибину сканування, розподіл ваги внутрішніх посилань і логічне групування контенту, яке і користувачі, і пошукові роботи використовують для визначення архітектури сайту.
Що насправді являє собою ієрархія сторінок WordPress під капотом
Сторінки WordPress зберігаються як спеціальний тип запису з post_type = 'page'. На відміну від записів, сторінки розроблені як ієрархічні — аргумент hierarchical у register_post_type() за замовчуванням встановлений у true для сторінок. Це вмикає поле post_parent, яке зберігає ID батьківської сторінки.
Глибина вкладеності теоретично необмежена, але функції get_page_hierarchy() та wp_list_pages() WordPress обходять дерево рекурсивно, що може спричинити накладні витрати на продуктивність на сайтах із сотнями глибоко вкладених сторінок.
Ключові поля бази даних:
post_parent — зберігає цілочисельний ID батьківської сторінки (0 означає відсутність батьківської сторінки)
post_name — слаг, що використовується при формуванні URL
menu_order — керує порядком відображення серед сторінок-сестер
Розуміння цієї структури є необхідним перед тим, як ви почнете будувати ієрархії контенту, особливо якщо ви керуєте великим сайтом у середовищі VPS Хостингу, де важлива оптимізація запитів до бази даних.
Коли використовувати батьківські сторінки: реальні критерії прийняття рішень
Не кожен багатосторінковий сайт потребує структури батьківської-дочірньої сторінки. Використовуйте її свідомо, а не за замовчуванням.
Використовуйте батьківські сторінки, коли:
У вас є три або більше сторінок, що мають спільну тематичну область і виграють від згрупованої навігації
Ви хочете ієрархічні URL, які сигналізують пошуковим системам про зв’язки між контентом (наприклад, /services/seo/ під /services/)
Архітектура вашого сайту побудована за моделлю «хаб і спиці», де опорна сторінка є центром кластера допоміжних сторінок
Вам потрібна правильна робота навігаційних «хлібних крихт» — більшість плагінів і тем для хлібних крихт покладаються на post_parent для генерації точних ланцюжків
Уникайте батьківських сторінок, коли:
Зв’язок між сторінками є слабким або надуманим — штучна ієрархія створює заплутані URL і вводить в оману пошукових роботів
У вас лише дві пов’язані сторінки — плоска структура з внутрішніми посиланнями є чистішим рішенням
Ви будуєте сайт у стилі блогу, де таксономія (категорії, теги) є більш відповідним інструментом організації, ніж ієрархія сторінок
Як встановити батьківську сторінку в WordPress: покрокова інструкція
Використання блокового редактора (Gutenberg)
Перейдіть до Сторінки > Додати нову або відкрийте існуючу сторінку для редагування.
На правій бічній панелі відкрийте вкладку Сторінка (не вкладку Блок).
Прокрутіть до панелі Атрибути сторінки та розгорніть її.
У випадаючому списку Батьківська сторінка виберіть потрібну батьківську сторінку. Якщо батьківська сторінка не потрібна, залиште значення (без батьківської).
За бажанням встановіть поле Порядок, щоб керувати позицією сторінки серед сторінок-сестер.
Натисніть Опублікувати або Оновити.
Використання класичного редактора
Відкрийте редактор сторінки.
Знайдіть мета-блок Атрибути сторінки на правій бічній панелі.
Виберіть батьківську сторінку зі списку Батьківська.
Натисніть Оновити.
Програмне встановлення батьківських сторінок (WP-CLI або PHP)
Для масових операцій — наприклад, міграції плоскої структури сайту в ієрархію — використовуйте WP-CLI:
wp post update <child-page-id> --post_parent=<parent-page-id>
Або в PHP, використовуючи wp_update_post():
wp_update_post( array(
'ID' => 456, // Child page ID
'post_parent' => 123, // Parent page ID
) );
Цей підхід є незамінним при реструктуризації десятків сторінок одночасно без необхідності клікати через адміністративний інтерфейс.
Структура URL та наслідки для SEO
Найбільш відчутним технічним наслідком встановлення батьківської сторінки є зміна постійного посилання сторінки. WordPress формує URL шляхом конкатенації слагів усіх предків:
Сторінка
Слаг
Результуючий URL
Послуги (Батьківська)
services
/services/
SEO (Дочірня)
seo
/services/seo/
Локальне SEO (Онука)
local-seo
/services/seo/local-seo/
Про нас (Без батьківської)
about-us
/about-us/
Міркування щодо SEO:
URL-шляхи, насичені ключовими словами, сигналізують про тематичну релевантність на кожному рівні директорії. /services/web-design/ повідомляє і користувачам, і пошуковим роботам, що веб-дизайн є підрозділом послуг.
Глибина сканування збільшується з вкладеністю. Сторінки, заховані на три або чотири рівні вглиб, отримують менше проходів внутрішніх посилань від Googlebot. Тримайте критичні сторінки в межах двох кліків від головної сторінки.
Узгодженість канонічного URL — якщо ви коли-небудь зміните слаг батьківської сторінки, URL усіх дочірніх сторінок також зміняться. Це може спричинити масові помилки 404, якщо перенаправлення не налаштовані негайно. Завжди налаштовуйте 301 перенаправлення після реструктуризації.
Схема хлібних крихт — плагіни на кшталт Yoast SEO та Rank Math автоматично генерують структуровані дані BreadcrumbList використовуючи ланцюжок post_parent, що може давати розширені результати з хлібними крихтами в Google Search.
Порівняння: ієрархія сторінок vs. категорії vs. спеціальні таксономії
Поширена архітектурна помилка — використання ієрархії сторінок там, де краще підійде таксономія, або навпаки.
Функція
Ієрархія сторінок
Категорії
Спеціальні таксономії
Тип запису
Лише сторінки
Записи (за замовчуванням)
Будь-який зареєстрований тип запису
Структура URL
Успадкування слагів (/parent/child/)
URL архівів (/category/name/)
Налаштовувана
Підтримка хлібних крихт
Нативна через post_parent
Залежить від плагіна
Залежить від плагіна
Керування шаблонами
page-{slug}.php, page-{id}.php
category-{slug}.php
taxonomy-{taxonomy}.php
Найкраще для
Статичних кластерів контенту
Групування записів блогу
Складних моделей контенту
Ієрархічна
Так (необмежена глибина)
Так (батьківські категорії)
Необов’язково
SEO-сигнал URL
Сильний (вкладеність шляху)
Помірний
Налаштовуваний
Якщо ваш контент переважно редакційний (записи блогу, новинні статті), категорії та теги є правильним інструментом. Ієрархія сторінок спеціально призначена для статичного, структурного контенту: сторінок послуг, документації, юридичних сторінок та подібних кластерів вічнозеленого контенту.
Налаштування навігаційних меню для ієрархічних сторінок
WordPress не відображає ієрархію сторінок у навігаційних меню автоматично. Це потрібно налаштовувати вручну.
Створення вкладеного меню
Перейдіть до Зовнішній вигляд > Меню.
Додайте батьківську сторінку до меню.
Додайте дочірні сторінки до меню.
Перетягніть кожен елемент дочірньої сторінки трохи правіше під батьківську — це створює візуальний відступ у конструкторі меню, який WordPress інтерпретує як елемент підменю.
Натисніть Зберегти меню.
Результуючий HTML використовує вкладену структуру <ul> з класом sub-menu, яку більшість тем стилізує як випадаючу навігацію.
Автоматичне відображення дочірніх сторінок
Щоб відобразити список дочірніх сторінок у вмісті батьківської сторінки, використовуйте шорткод [subpages], якщо ваша тема або плагін підтримує його, або додайте це до шаблону сторінки:
<?php
$children = wp_list_pages( array(
'child_of' => get_the_ID(),
'title_li' => '',
'echo' => 0,
) );
if ( $children ) {
echo '<ul>' . $children . '</ul>';
}
?>
Це особливо корисно для хаб-сторінок, які слугують навігаційними індексами для свого дочірнього контенту.
Шаблони сторінок та ієрархічні патерни дизайну
Ієрархія шаблонів WordPress вирішує шаблони сторінок у такому порядку:
page-{slug}.phppage-{id}.phppage.phpsingular.phpindex.phpНе існує нативного шаблону parent-page.php або child-page.php. Щоб застосувати різні дизайни до батьківських та дочірніх сторінок, у вас є два варіанти:
Варіант 1: Умовна логіка в page.php
<?php
if ( $post->post_parent ) {
// This is a child page
get_template_part( 'template-parts/child-page' );
} else {
// This is a top-level page
get_template_part( 'template-parts/parent-page' );
}
?>Варіант 2: Спеціальні шаблони сторінок — Створіть файл шаблону (наприклад, template-hub-page.php) з коментарем-заголовком Template Name:, потім призначте його батьківським сторінкам через панель атрибутів сторінки. Це дає вам повний контроль над дизайном без необхідності торкатися page.php.
Поширені помилки та способи їх уникнення
Колізія слагів після реструктуризації — Якщо ви переміщуєте сторінку з верхнього рівня на дочірню позицію, її URL змінюється. Будь-які зовнішні зворотні посилання, що вказують на старий URL, отримають помилку 404, якщо ви не налаштуєте 301 перенаправлення. Використовуйте плагін для керування перенаправленнями або налаштуйте перенаправлення на рівні сервера у вашій конфігурації Nginx або Apache.
Кругове призначення батьківської сторінки — WordPress запобігає призначенню сторінки власною батьківською в інтерфейсі, але програмні призначення можуть створювати кругові посилання, які порушують get_ancestors() та спричиняють нескінченні цикли у спеціальному коді. Завжди перевіряйте значення post_parent у спеціальних скриптах імпорту.
Глибокі ієрархії, що погіршують продуктивність — get_page_hierarchy() виконує один запит, але обробляє дерево в PHP. На сайтах із 500+ сторінками та чотирма або більше рівнями вкладеності це може стати повільним. Розгляньте можливість вирівнювання ієрархії та використання спеціальних полів або таксономій для логічного групування замість цього.
Невідповідність глибини меню та глибини сторінок — Глибина вашого навігаційного меню не повинна відображати глибину ієрархії сторінок. Сторінка може бути онукою в структурі URL, але відображатися як прямий дочірній елемент у меню. Це незалежні конфігурації.
Необхідність скидання постійних посилань — Після зміни призначень батьківських сторінок завжди переходьте до Налаштування > Постійні посилання та натискайте Зберегти зміни (нічого не змінюючи), щоб скинути кеш правил перезапису. Якщо цього не зробити, можуть виникнути помилки 404 для нових структурованих URL.
Практичні приклади архітектури
Корпоративний сайт послуг
/services/ (Parent — hub page)
/services/web-design/ (Child)
/services/web-design/branding/ (Grandchild — use sparingly)
/services/seo/ (Child)
/services/digital-marketing/ (Child)Документація або база знань
/docs/ (Parent)
/docs/getting-started/ (Child)
/docs/api-reference/ (Child)
/docs/troubleshooting/ (Child)Для сайтів документації, що працюють на самостійно керованому сервері, VPS з cPanel надає гнучкість для налаштування спеціальних структур постійних посилань і рівнів кешування без обмежень спільного хостингу.
Юридичні / Правові сторінки
/legal/ (Parent)
/legal/privacy-policy/ (Child)
/legal/terms-of-service/ (Child)
/legal/cookie-policy/ (Child)Ця структура тримає юридичні сторінки організованими, спрощує їх посилання з підвалів і сигналізує пошуковим роботам, що вони утворюють узгоджену групу контенту.
WordPress Multisite та ієрархія сторінок
У мережі WordPress Multisite ієрархії сторінок є специфічними для сайту — кожен підсайт підтримує власну таблицю wp_X_posts, де X є ID сайту. Міжсайтової ієрархії сторінок не існує. Якщо ви запускаєте мультисайтову інсталяцію на Виділеному сервері для ізоляції продуктивності, майте на увазі, що загальномережеві навігаційні меню не можуть успадковувати ієрархії сторінок від окремих підсайтів.
Контрольний список ключових технічних висновків
Перед впровадженням або реструктуризацією ієрархії сторінок на будь-якому сайті WordPress перевірте наступне:
- Аудит існуючих URL — задокументуйте всі поточні URL сторінок перед зміною будь-яких призначень батьківських сторінок
- Налаштуйте 301 перенаправлення — для кожного URL, який зміниться в результаті реструктуризації
- Скиньте постійні посилання — відвідайте Налаштування > Постійні посилання та збережіть після будь-якої зміни батьківської-дочірньої сторінки
- Обмежте глибину вкладеності — два рівні охоплюють переважну більшість випадків використання; три рівні є практичним максимумом, після якого страждають глибина сканування та UX
- Перевірте слаги — переконайтеся, що кожна сторінка в ієрархії має чистий, релевантний ключовим словам слаг без стоп-слів або надлишкових термінів
- Перевірте виведення хлібних крихт — підтвердьте, що ваш SEO-плагін генерує правильні структуровані дані
BreadcrumbListпісля реструктуризації - Перевірте конфігурацію меню — оновлюйте навігаційні меню вручну; вони не оновлюються автоматично при зміні ієрархії сторінок
- Перегляньте внутрішні посилання — будь-які жорстко закодовані внутрішні посилання на сторінки, URL яких змінилися, необхідно оновити
- Використовуйте WP-CLI для масових змін — ніколи не редагуйте
post_parentбезпосередньо в базі даних без резервної копії - Спочатку тестуйте на стейджингу — реструктуризація ієрархії URL живого сайту без стейджингового середовища є операцією з високим ризиком
Якщо ваша інсталяція WordPress розміщена на плані VPS Хостингу, у вас є доступ на рівні сервера, необхідний для налаштування правил перезапису Nginx або перенаправлень Apache .htaccess безпосередньо — значна перевага над спільним хостингом при управлінні масштабною реструктуризацією URL.
Для сайтів, які також покладаються на транзакційну електронну пошту (підтвердження замовлень, сповіщення контактних форм), переконайтеся, що конфігурація вашого Хостингу електронної пошти відокремлена від вашого веб-сервера, щоб запобігти проблемам з доставкою під час будь-яких змін конфігурації на рівні сервера, що здійснюються паралельно з реструктуризацією сайту.
FAQ
Чи автоматично створює WordPress перенаправлення зі старого URL при зміні батьківської сторінки?
Ні. WordPress не генерує автоматичні 301 перенаправлення при зміні призначення батьківської сторінки та оновленні її URL. Вам потрібно вручну створити перенаправлення за допомогою плагіна, наприклад Redirection, або налаштувавши правила перезапису на рівні сервера. Якщо цього не зробити, старі URL отримуватимуть помилки 404.
Чи можна вкладати сторінки WordPress більш ніж на два рівні?
Так, WordPress підтримує необмежену глибину вкладеності на рівні бази даних. Однак більшість найкращих практик SEO та рекомендацій UX радять максимум два-три рівні. Сторінки глибше трьох рівнів отримують менше проходів внутрішніх посилань від пошукових роботів і є складнішими для інтуїтивної навігації користувачів.
Чи впливає ієрархія сторінок на SEO WordPress безпосередньо?
Так, двома конкретними способами. По-перше, URL-шлях успадковує слаги батьківських сторінок, створюючи насичені ключовими словами, описові URL, що сигналізують про тематичні зв’язки. По-друге, плагіни хлібних крихт використовують ланцюжок post_parent для генерації структурованих даних BreadcrumbList, які можуть відображатися як розширені результати з хлібними крихтами в Google Search і покращувати показники клікабельності.
Що відбувається з дочірніми сторінками при видаленні батьківської?
Коли ви видаляєте батьківську сторінку в WordPress, дочірні сторінки не видаляються — вони автоматично підвищуються до сторінок верхнього рівня (їх значення post_parent скидається до 0). Їх URL змінюються відповідно, що може порушити внутрішні посилання та генерувати помилки 404. Завжди перепризначайте або перенаправляйте перед видаленням батьківської сторінки.
Чи можна використовувати ієрархію сторінок та спеціальне навігаційне меню незалежно?
Так, і це поширений патерн. Ієрархія сторінок визначає структуру URL та ланцюжки хлібних крихт, тоді як навігаційне меню є повністю окремою конфігурацією. Сторінка може бути онукою в ієрархії URL, але відображатися як елемент верхнього рівня у вашому меню, або взагалі бути виключеною з меню. Ці дві системи не повинні відображати одна одну.