Кореневий каталог: що це таке і як працювати з ним без помилок

Кореневий каталог — це відправна точка у файловій ієрархії. У системі він позначається слешем / і містить усе інше. На хостингу — це конкретна папка (найчастіше public_html або httpdocs), куди вебсервер дивиться, коли відвідувач заходить на ваш домен. Від того, чи правильно визначено цей каталог, залежить, чи відкриється сайт, чи побачить користувач потрібні файли і чи не з’являться помилки 403 або 404.

Багато хто плутає кореневий каталог операційної системи з кореневим каталогом сайту. Наслідок — файли завантажуються «не туди», сайт не працює або показує вміст чужої папки. У реальних проєктах саме ця плутанина найчастіше змушує вебмайстрів годинами шукати причину, чому після завантаження файлів нічого не змінилося.

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

Два кореневих каталоги, які важливо розрізняти

У Linux-сервері існує один кореневий каталог файлової системи — `/`. Він є вершиною ієрархії: звідси починаються всі абсолютні шляхи. Усередині нього розташовані системні папки, домашні каталоги користувачів і, зокрема, папки ваших сайтів.

Кореневий каталог сайту (document root) — це вже інше поняття. Це папка, яку вебсервер (Apache, Nginx, LiteSpeed) налаштовано вважати стартовою для конкретного домену або піддомену. Зазвичай вона знаходиться всередині домашнього каталогу користувача: `/home/username/public_html` або `/home/username/domains/example.com/public_html`. Коли хтось заходить на example.com, сервер шукає файл `index.php` або `index.html` саме в цій папці.

Якщо ви завантажите файли сайту на рівень вище — у `/home/username/` — сервер їх не побачить. Якщо завантажите в підпапку `public_html/site` — сайт відкриватиметься за адресою example.com/site. Розуміння різниці між системним коренем і document root економить час і нерви.

Кореневий каталог у Linux: як влаштована файлова система

Стандарт FHS (Filesystem Hierarchy Standard) визначає, що має бути в кореневому каталозі `/` будь-якого Linux-дистрибутива. Це не випадковий набір папок — кожна виконує чітку роль.

/bin і /sbin містять базові виконувані файли, потрібні навіть у режимі відновлення. /etc — це місце для системних конфігурацій: тут лежать налаштування мережі, користувачів, сервісів. /home — домашні каталоги звичайних користувачів. У кожного свій ізольований простір. /root — домашня папка суперкористувача root.

/usr зберігає більшість програм і бібліотек. /var — змінні дані: логи, кеш, черги. /tmp — тимчасові файли, які зазвичай очищуються при перезавантаженні. Є ще віртуальні файлові системи /dev, /proc, /sys, які відображають пристрої та процеси ядра.

Практичне значення: абсолютний шлях завжди починається з `/`. Команда `cd /home/username/public_html` перемістить вас точно в кореневий каталог сайту. Команда `ls /` покаже вміст самого верху системи. Помилки на рівні кореня небезпечні — неправильна команда `rm` може зачепити системні файли. Тому в продакшені працюють через звичайного користувача і sudo лише за потреби.

Кореневий каталог сайту: де вебсервер шукає ваші файли

Вебсервер не «бачить» усю файлову систему однаково. Для кожного домену в конфігурації віртуального хоста прописано директиву DocumentRoot (або root у Nginx). Саме цей шлях сервер підставляє до запиту користувача.

Якщо запитується example.com/page, сервер шукає файл у `DocumentRoot/page`. Якщо це директорія — шукає `index.php` або `index.html` (залежить від налаштувань). Якщо файлу немає — 404. Якщо директорія існує, а індексного файлу немає і дозволено listing — користувач побачить список файлів. Це і є типова картина, коли сайт «не відкривається» після завантаження.

Найпоширеніші назви кореневого каталогу сайту на українських хостингах: `public_html` (більшість shared-хостингів), `httpdocs` (Plesk), `www` або `htdocs`. У деяких панелях для додаткових доменів і піддоменів створюються окремі папки всередині `domains` або `subdomains`.

Як знайти та перевірити кореневий каталог у популярних панелях

Шлях залежить від панелі керування. Ось актуальна картина на 2026 рік:

Інформація узагальнена на основі інтерфейсів панелей станом на 2026 рік. Точний шлях завжди перевіряйте у своїй панелі — він може відрізнятися залежно від провайдера та типу тарифу.

Після того як знайшли папку, створіть у ній простий файл `index.html` з текстом «Тест кореневого каталогу» і перевірте сайт у браузері. Якщо файл з’явився — шлях правильний.

Поширені помилки при роботі з кореневим каталогом і способи їх виправлення

Файли завантажено не в ту папку. Найчастіша причина «мертвого» сайту після завантаження. Файли опинилися в `/home/username/` або в підпапці. Виправлення: перемістіть файли у правильний `public_html` через файловий менеджер або FTP. Якщо панель дозволяє — змініть Document Root на потрібну папку.

Завантажено всю папку WordPress замість її вмісту. Сайт відкривається за адресою example.com/wordpress. Рішення: перемістіть файли на рівень вище або змініть document root на `public_html/wordpress` і оновіть константи в `wp-config.php` або через БД.

Неправильні права доступу. Папки з правами 777 або файли з 600 часто викликають 403 Forbidden. Стандарт: папки — 755, файли — 644. Власник зазвичай `користувач:користувач` або `www-data`. Виправляйте через файловий менеджер або команди `chmod` і `chown` у SSH.

Для додаткового домену або піддомену не оновлено document root. Панель створила папку, але не змінила налаштування віртуального хоста. Зайдіть у налаштування домену і вкажіть правильний шлях.

Конфлікт .htaccess. Файл у корені блокує доступ або створює зациклені редиректи. Перейменуйте його тимчасово на `.htaccess.bak` і перевірте сайт. Якщо запрацювало — розбирайте синтаксис.

Після міграції WordPress не оновлено URL. У БД залишилися старі значення siteurl і home. Використовуйте плагін Better Search Replace або SQL-запит для заміни шляхів.

Увімкнено directory listing. Користувачі бачать список файлів. Додайте в `.htaccess` рядок `Options -Indexes` або вимкніть у налаштуваннях сервера.

Безпека кореневого каталогу: що розміщувати, а що — ні

У кореневому каталозі сайту мають бути лише публічні файли: HTML, CSS, JavaScript, зображення, точки входу PHP. Конфігураційні файли з паролями (`wp-config.php`, `.env`, файли підключення до БД) краще тримати з правами 600. Якщо можливо — виносьте секрети за межі web root і підключайте через змінні оточення або окремий файл вище по ієрархії.

Ніколи не залишайте в корені `.git`, бекапи, `phpinfo.php`, тестові скрипти. Вони дають зловмиснику інформацію про структуру та версії. Регулярно перевіряйте папку на зайві файли. Використовуйте SFTP замість FTP — трафік шифрується.

У системному корені Linux (`/`) правило ще жорсткіше: звичайний користувач не повинен мати права на запис у системні папки. Всі зміни — через sudo і тільки обґрунтовано.

Практичні сценарії: від першого сайту до складних налаштувань

Сценарій 1. Перше завантаження статичного сайту. Створіть у `public_html` файл `index.html`. Завантажте решту файлів. Перевірте доступність. Якщо з’явився дефолтний сторінка хостингу — значить, document root налаштовано на іншу папку або файли лежать не там.

Сценарій 2. Додавання піддомену blog.example.com. У панелі створюєте піддомен. Зазвичай автоматично створюється папка `public_html/blog` або окрема директорія. Перевірте document root у налаштуваннях піддомену і переконайтеся, що він вказує саме туди, куди ви плануєте завантажувати файли блогу.

Сценарій 3. Перенесення WordPress з підкаталогу в корінь. Перемістіть файли на рівень `public_html`. Оновіть `siteurl` і `home` у таблиці `wp_options`. Очистіть кеш і перевірте посилання. Якщо використовуєте Bedrock або кастомну структуру — змініть document root на папку `web`.

Сценарій 4. Робота через SSH. Підключіться, виконайте `cd /home/username/public_html` (або ваш шлях). Перевіряйте файли командами `ls -la`, редагуйте через `nano` або `vim`. Після змін перевіряйте права і перезапускайте сервіси за потреби (php-fpm, nginx).

Кореневий каталог у сучасних рішеннях 2026 року

На VPS і виділених серверах ви повністю контролюєте конфігурацію віртуальних хостів. Можна вказати будь-який шлях як document root, навіть за межами стандартних папок. У Docker кожен контейнер має власну ізольовану кореневу файлову систему. Зазвичай застосунок розміщують у `/app` або `/usr/src/app`, а вебсервер налаштовують на цю директорію. Root контейнера — це не root хоста.

У статичних хостингах і Jamstack-платформах (Vercel, Netlify, Cloudflare Pages) поняття «кореневий каталог» трансформувалося в «publish directory» або «output directory». Ви вказуєте папку збірки (`dist`, `out`, `build`), і платформа розгортає саме її вміст. Традиційного вебсервера з document root немає — є edge-мережа, яка віддає статичні файли.

У 2026 році тренд — максимальна ізоляція. Навіть на shared-хостингу провайдери посилюють розділення прав між акаунтами та доменами. Контейнеризація і serverless-підходи зменшують поверхню атаки саме тому, що кожен проєкт працює у своєму обмеженому середовищі з чітко визначеним «коренем».

Розуміння кореневого каталогу — це не абстрактна теорія. Це практична навичка, яка дозволяє швидко діагностувати проблеми, безпечно розгортати проєкти і уникати більшості типових помилок. Почніть з перевірки шляху у своїй панелі керування — у 80 % випадків саме там криється причина, чому сайт не працює так, як ви очікували.