Базовая структура проекта сайта: файлы и папки

Структура проекта — это не просто красивые папки. Это фундамент, который либо сэкономит вам часы работы, либо превратит разработку в бесконечный поиск нужного файла. Когда я только начинал верстать сайты на заказ, у меня была папка site_final, внутри site_final2, а рядом site_final_final. Казалось, что так удобнее, но на деле любое обновление превращалось в квест «найди актуальный файл». Правильная организация с самого начала убирает эту боль.

Зачем вообще нужна структура проекта

У новичков часто всё лежит «в куче»: index.html, картинки, стили, скрипты, архивы и черновики в одной папке. На маленьком проекте это терпимо, но быстро превращается в хаос. Я не раз видел, как после пары недель работы автор сам путался, где лежит последняя версия скрипта, и случайно подключал старый файл.

Хорошая структура нужна, чтобы:

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

На практике удобнее всего сразу отделять HTML-страницы, стили, скрипты, изображения и дополнительные ресурсы. Именно такой подход чаще всего используется в учебных и реальных проектах веб-разработки. И он же ложится в основу любой автоматизации: хотите потом подключить Gulp или Webpack — структура уже готова.

Что лежит в корне проекта

Корень проекта — это главная папка сайта. Именно отсюда обычно начинается структура. Здесь не должно быть свалки: только то, что действительно относится ко всему сайту целиком.

Минимальный набор для простого сайта выглядит так:

• index.html — главная страница;
• styles/ или css/ — стили;
• scripts/ или js/ — JavaScript;
• images/ или img/ — изображения;
• fonts/ — шрифты, если они используются локально.

В более аккуратных проектах в корне также могут лежать:

• robots.txt — инструкции для поисковых роботов;
• sitemap.xml — карта сайта;
• .htaccess — настройки сервера для Apache (если хостинг на нём);
• favicon.ico или другие файлы иконки сайта.

Важно понимать: в корне лучше держать только то, что действительно должно быть рядом и использоваться на уровне всего сайта. Всё остальное удобнее убирать в подпапки. Например, если вы храните там черновик_дизайна.psd или node_modules.zip — это первый признак будущего беспорядка.

Базовая структура папок для небольшого сайта

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

project/
├── index.html
├── about.html
├── contacts.html
├── css/
│   └── style.css
├── js/
│   └── main.js
├── images/
│   ├── hero.jpg
│   └── logo.svg
└── fonts/
    └── roboto.woff2

Такой вариант удобен тем, что:

• HTML-файлы лежат отдельно — сразу видно, какие страницы есть;
• стили не смешиваются с картинками — не нужно гадать, где искать background-image;
• JavaScript легко найти — один входной файл или несколько модулей в одной папке;
• изображения и шрифты собраны в своих папках — при замене картинки не затронете код;
• проект выглядит аккуратно уже на первом этапе — это дисциплинирует и заказчика, и разработчика.

Какие папки встречаются чаще всего

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

На практике я часто встречаю img/ вместо images/ — это дело вкуса, главное — не смешивать оба варианта в одном проекте. То же касается js/ и scripts/. Выберите один стиль и придерживайтесь его.

Как организовать страницы сайта

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

Вариант 1. Страницы в корне

Подходит для небольшого сайта: лендинг, портфолио из 3–5 страниц. Все HTML-файлы лежат прямо в корневой папке.

project/
├── index.html
├── about.html
├── services.html
├── contacts.html
├── css/
├── js/
└── images/

Плюсы:

• простая структура — не нужно запоминать вложенность;
• легко объяснить новичку — все страницы на виду;
• быстро открыть любую страницу — путь к файлу короткий и очевидный.

Минусы:

• при росте проекта корень быстро захламляется — десять HTML-файлов уже создают визуальный шум;
• неудобно, если страниц становится много — сложно группировать по разделам.

Вариант 2. Отдельные папки под разделы

Подходит, если сайт уже не совсем маленький: интернет-магазин, корпоративный портал, блог с категориями. Каждый раздел получает свою папку, а внутри — свой index.html или страницы.

project/
├── index.html
├── about/
│   └── index.html
├── services/
│   ├── index.html
│   ├── web-development.html
│   └── seo.html
├── contacts/
│   └── index.html
├── css/
├── js/
└── images/

Плюсы:

• логичная группировка по разделам — сразу понятно, где искать страницу «Разработка сайтов»;
• удобно масштабировать — добавляете новую услугу как папку с файлами;
• легче поддерживать крупный сайт — каждый раздел можно развивать независимо.

Минусы:

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

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

Как хранить изображения

С картинками чаще всего возникает беспорядок. Я не раз видел папку images/, где вперемешку лежали иконки, фотографии товаров, фоны и скриншоты с ошибками. Чтобы этого избежать, изображения лучше не складывать в одну общую кучу.

Удобная схема — разделение по назначению:

images/
├── icons/
│   ├── phone.svg
│   └── email.svg
├── photos/
│   ├── team-01.jpg
│   └── office.jpg
└── backgrounds/
    └── hero-bg.jpg

Или проще — по расположению на сайте:

images/
├── home/
│   ├── hero.jpg
│   └── features-icons.svg
├── about/
│   └── team.jpg
└── common/
    ├── logo.svg
    └── favicon.ico

Практический совет: называйте файлы понятно и без пробелов, например:

• hero-banner.jpg — сразу ясно, что это главный баннер;
• team-photo-01.jpg — порядковый номер и контекст;
• icon-phone.svg — тип и назначение.

Плохие примеры:

• IMG_1234.jpg — что на картинке, непонятно;
• image1-final-new-new.jpg — версионный хаос;
• логотип (1).png — пробелы и кириллица могут вызвать проблемы на сервере.

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

Как хранить стили и скрипты

Для стилей обычно используют папку css/ или styles/. Я предпочитаю css/ — она короче и привычнее.

Пример минимальной организации:

css/
├── style.css          (основные стили)
├── normalize.css      (сброс стилей)
└── responsive.css     (адаптивность)

Если проект небольшой, одного файла style.css вполне достаточно. Но если сайт разрастается, удобнее разделять стили по смыслу: базовые, компоненты, страницы. Например:

css/
├── base/
│   ├── reset.css
│   └── typography.css
├── components/
│   ├── buttons.css
│   ├── header.css
│   └── cards.css
└── pages/
    ├── home.css
    └── about.css

Для JavaScript обычно создают папку js/ или scripts/. Я придерживаюсь модульного подхода даже в небольших проектах — это дисциплинирует.

js/
├── main.js            (точка входа)
├── modules/
│   ├── slider.js
│   ├── form.js
│   └── map.js
└── vendor/
    └── jquery.min.js

Такой подход помогает не превращать один файл в «свалку» из кода. Каждый модуль отвечает за свою задачу: слайдер — отдельно, валидация формы — отдельно. Когда нужно что-то поправить, вы не пролистываете тысячи строк в поисках нужного обработчика.

Что такое assets и когда она полезна

Папка assets/ — это общий контейнер для статических файлов. Она полезна, когда хочется собрать ресурсы в одном месте, особенно если проект использует сборщики или подключается к CMS.

Пример:

assets/
├── css/
├── js/
├── images/
├── fonts/
└── icons/

Это удобно в проектах, где ресурсы нужны не только для фронтенда, но и для сборки, шаблонов или CMS. Например, в WordPress я часто выношу пользовательские стили и скрипты в assets/ внутри темы — так проще подключать их через wp_enqueue_style().

Когда использовать assets/:

• в средних и крупных проектах — когда файлов много и нужна единая точка входа;
• если нужна единая точка для всех ресурсов — сборщик вроде Webpack будет забирать всё из assets/;
• если команда привыкла к такой логике — не стоит ломать устоявшиеся соглашения.

Когда можно обойтись без неё:

• в очень маленьком сайте — лишняя вложенность только усложнит;
• если структура и так понятна без лишней вложенности — css/, js/, images/ в корне вполне самодостаточны.

Типовые ошибки в структуре проекта

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

• Все файлы лежат в одной папке. Классика: index.html в окружении десятка картинок, трёх CSS и двух JS. Найти нужное — целое приключение.
• Названия папок дублируются без смысла: new/, final/, final2/, new-final/. Через неделю уже не вспомнить, какая версия актуальна.
• Картинки хранятся вперемешку с HTML и CSS. Тогда путь к файлу в стилях выглядит как url(../../../img.jpg) — легко ошибиться.
• Нет понятной логики именования. Файлы типа 1.jpg, 2.png — при замене картинки приходится гадать, что это.
• Слишком глубокая вложенность папок. Если путь к файлу содержит 6–7 уровней, вы тратите время на навигацию, а не на разработку.
• В корне лежат десятки временных файлов. Черновики, архивы, старые версии — всё это должно храниться отдельно, например, в папке _archive/ за пределами проекта.
• Один большой style.css и один огромный script.js без разделения. Когда стилей на 3000 строк, править что-то становится страшно — боишься сломать всё сразу.
• Путь к файлу написан с ошибкой из-за хаоса в структуре. Например, в HTML подключается css/style.css, а реально файл лежит в styles/main.css — и вёрстка ломается.

Хорошая структура не должна быть слишком сложной. Если для поиска нужного файла приходится «проваливаться» через 6–7 уровней папок, структура уже перегружена. Держите в голове правило: любой файл должен находиться за 2–3 клика.

Практическая схема для старта

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

project/
├── index.html
├── css/
│   └── style.css
├── js/
│   └── main.js
├── images/
│   ├── icons/
│   └── photos/
└── fonts/

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

Как проверять, что структура удобная

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

• Понимаю ли я, где лежит каждый тип файла? Если нужно объяснить другому человеку, смогу ли я сделать это за минуту?
• Могу ли я найти нужный ресурс за 5–10 секунд? Откройте проект и попробуйте найти файл стилей или конкретную иконку — если уходит больше времени, структура требует доработки.
• Не дублируются ли файлы с одинаковой ролью? Например, два файла header.css в разных папках — верный признак путаницы.
• Не слишком ли много всего лежит в корне? Если там больше 7–10 элементов, пора раскладывать по папкам.
• Будет ли удобно расширять сайт через месяц? Представьте, что нужно добавить раздел «Портфолио» с десятью страницами — текущая структура выдержит или начнёт трещать по швам?

Если на часть вопросов ответ «нет», структуру лучше упростить или пересобрать сразу, пока проект маленький. Потом переезд будет стоить гораздо дороже.

Чек-лист для базовой структуры сайта

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

• Есть index.html в корне.
• Стили лежат отдельно в css/ или styles/.
• Скрипты лежат отдельно в js/ или scripts/.
• Изображения собраны в images/ или img/.
• Шрифты вынесены в fonts/, если используются локально.
• Названия файлов понятные и без хаоса: никаких final_final2.
• В корне нет лишнего мусора: черновики, архивы, файлы «на всякий случай» убраны.
• Структура не мешает расширять сайт: при добавлении 10 новых страниц не придётся всё перекраивать.

Пошагово: как собрать структуру с нуля

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

Шаг 1. Создайте корневую папку проекта

Назовите её просто и понятно, без пробелов и лишних символов. Хорошо: my-site, landing-company. Плохо: Сайт для клиента (финал) — пробелы и кириллица могут аукнуться при работе с сервером или Git.

Шаг 2. Добавьте главный HTML-файл

Обычно это index.html. Именно его веб-сервер отдаёт по умолчанию при обращении к корню сайта. Если проект многостраничный, на этом этапе можно сразу создать заготовки для остальных страниц или папок разделов.

Шаг 3. Создайте папки для ресурсов

Минимум: css/, js/, images/. Я обычно сразу добавляю fonts/, даже если шрифты пока не используются — это напоминает, что типографика важна, и не даёт потом искать место для файлов.

Шаг 4. Разложите файлы по назначению

Стили — в CSS, скрипты — в JS, картинки — в images. Если уже есть контент, сразу распределите его. Не оставляйте «временные» файлы в корне — они имеют свойство становиться постоянными.

Шаг 5. Проверьте пути к подключаемым файлам

Особенно важно не ошибиться в относительных путях. В index.html ссылка на стили должна выглядеть как href="css/style.css", а не href="../css/style.css". Проверьте, что все картинки и скрипты подгружаются.

Шаг 6. Уберите временные файлы

Черновики, архивы и старые версии лучше хранить отдельно, не внутри рабочей структуры. Я для таких целей создаю папку _archive/ на уровень выше проекта. Тогда в рабочей папке остаётся только актуальный код.

FAQ

Какая структура проекта сайта считается самой удобной?

Для небольшого сайта чаще всего удобна простая схема: index.html, папки css/, js/, images/, fonts/. Она понятна новичкам и легко масштабируется. Главное — не усложнять без необходимости. Я не раз видел, как начинающие пытались скопировать структуру крупного фреймворка для лендинга из трёх блоков — это только добавляло путаницы.

Можно ли хранить CSS и JS прямо в HTML?

Можно, но для реального проекта это неудобно. Отдельные файлы проще поддерживать, переиспользовать и редактировать. Представьте, что вам нужно поменять цвет кнопок на всём сайте — в отдельном CSS вы сделаете это за минуту, а если стили размазаны по всем HTML-страницам, придётся править каждый файл. Кроме того, внешние файлы кешируются браузером, что ускоряет загрузку.

Что лучше: img или images?

Оба варианта допустимы. Главное — выбрать один стиль и соблюдать его во всём проекте. Я предпочитаю images/, потому что название полное и не вызывает вопросов у новичков. Но если вы работаете в команде, где принято img/ — следуйте общему соглашению.

Сколько уровней вложенности нормально?

Обычно достаточно 2–3 уровней. Слишком глубокая структура усложняет поддержку и поиск файлов. Например, путь assets/images/icons/social/facebook.svg уже на грани. Если иконок много, лучше хранить их в одной папке icons/ и давать понятные имена, а не создавать подпапку под каждую соцсеть.

Нужна ли папка assets?

Не всегда. Она полезна, если хочется собрать все ресурсы в одном месте, но для маленького сайта без неё вполне можно обойтись. Если вы используете сборщик типа Webpack, он по умолчанию ожидает папку src/assets/ — тогда есть смысл её завести. В чистом HTML/CSS/JS проекте я обычно обхожусь без неё.

Вывод

Базовая структура проекта сайта — это не формальность, а рабочий инструмент. Чем понятнее разложены файлы и папки, тем проще верстать, подключать стили и скрипты, находить ошибки и развивать сайт дальше. Начинать лучше с простой, логичной схемы и не усложнять её без необходимости. Когда структура выстроена правильно, разработка идёт быстрее, а сам проект выглядит профессионально уже на уровне организации файлов. И да — привычка сразу раскладывать всё по папкам окупается с первого же коммерческого заказа, когда правки от клиента приходят в пятницу вечером, а вы находите нужный файл за пару секунд.