Сайт на чистом html

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

Что происходит, когда открывается статическая страница

Разница между статикой и движком видна на уровне одного запроса. Браузер просит у сервера адрес, и дальше сценарии расходятся.

На статическом сайте веб-сервер находит на диске файл вроде uslugi/remont.html, отдаёт его как есть и закрывает соединение. Никакой обработки: содержимое файла на сервере и содержимое, которое увидел пользователь, совпадают побайтово.

На сайте с движком запрос принимает тот же веб-сервер, но передаёт его интерпретатору PHP (или другому языку). Тот загружает ядро системы, подключает активные модули и плагины, делает несколько десятков запросов к базе данных, подставляет полученные данные в шаблон и только затем возвращает готовый HTML. Всё это происходит заново при каждом обращении, если не включено кэширование.

Отсюда растут и все плюсы статики, и все её ограничения. Нечего исполнять — нечему тормозить и нечего взломать. Но нечего исполнять означает и то, что никакой логики на сервере нет: ни личного кабинета, ни поиска, ни фильтров, ни приёма форм.

Статика против движка: сравнение по параметрам

Сводка по тем характеристикам, которые реально влияют на работу с сайтом. Оценки даны для типового случая: чистый HTML на обычном хостинге против популярной CMS без глубокой оптимизации.

Параметр	Чистый HTML	Сайт на движке
Время ответа сервера	Десятки миллисекунд, стабильно	От сотни миллисекунд до нескольких секунд, зависит от плагинов и кэша
База данных	Отсутствует	Обязательна, требует резервных копий и обслуживания
Админка	Отсутствует, правки в коде	Есть, редактирование через браузер
Добавление новой страницы	Создать файл, добавить в меню на всех страницах, обновить sitemap	Нажать кнопку, заполнить поля
Уязвимости	Только на уровне сервера	Ядро, темы, плагины, база, права доступа
Обновления	Не требуются	Регулярно, с риском конфликтов
Требования к хостингу	Минимальные, подходит статический хостинг и CDN	PHP нужной версии, база, память, иногда отдельный сервер
Поиск по сайту, фильтры	Нет из коробки, нужен сторонний сервис или JS	Штатная функция
Формы заявок	Внешний сервис или отдельный обработчик	Плагин или модуль формы
Роли сотрудников	Нет	Есть: автор, редактор, администратор
Масштаб без боли	Единицы и десятки страниц	Сотни и тысячи страниц
Стоимость правки контента	Час подрядчика	Пять минут менеджера

Скорость: главный и честный аргумент за статику

Быстрее отдать готовый файл невозможно в принципе. Всё, что делает движок, — это попытка приблизиться к статике: кэширование страниц целиком, кэш объектов, предварительная генерация HTML. Хорошо настроенный движок с полностраничным кэшем отдаёт по сути ту же статику, просто сгенерированную заранее.

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

Безопасность: меньше кода — меньше поверхности атаки

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

Это не абсолютная защита. Остаются:

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

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

Хостинг, контроль над кодом и обновления

Статический сайт живёт где угодно: простейший тариф виртуального хостинга, объектное хранилище с раздачей по HTTP, CDN, бесплатные площадки для статики. Требований к памяти и версии PHP нет, значит нет и ситуации «хостер поднял версию, сайт лёг».

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

Тему разбирал отдельно: «Создание сайта на чистом html коде».

Полный контроль над кодом.

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

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

Помогу с продвижением: продвижение сайта в Яндексе — вывожу сайты в топ Яндекса белыми методами.

Ничего не ломается при обновлениях.

Сайт на движке требует внимания просто по факту существования: выходят обновления ядра, тем, плагинов, меняются версии PHP на хостинге. Отсутствие обновлений опасно (дыры), наличие — тоже (конфликты). Статический сайт в этом смысле стоит на месте: если файлы не трогать, через пять лет он откроется точно так же, как сегодня.

Минус первый: любая правка требует разработчика

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

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

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

Минус второй: нет удобного добавления материалов

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

Минус третий: поиск, фильтры, формы

Без серверной логики нет привычных функций.

• Поиск по сайту. Решается подключением внешнего поискового сервиса или клиентским поиском по заранее собранному индексу. Работает, но требует поддержки индекса.
• Фильтры и сортировки. На небольшом каталоге реализуются на JavaScript по данным в JSON, но каждая комбинация фильтров не имеет собственного адреса, а значит не может быть посадочной страницей под запрос.
• Формы. Отправить письмо чистый HTML не умеет. Нужен внешний обработчик: сервис форм, серверная функция, скрипт на стороннем хостинге. Плюс защита от спама и передача заявок в CRM.
• Личные кабинеты, корзина, оплата. Только через сторонние сервисы, встроенные виджетами.

Минус четвёртый: масштабирование

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

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

Смежный материал по теме — «Как продвинуть сайт в поисковиках».

Минус пятый: нет ролей и совместной работы

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

Влияет ли чистый HTML на позиции в поиске

Поисковой системе безразлично, чем сгенерирован HTML. Робот получает готовый код страницы и оценивает содержимое: соответствие запросу, полноту ответа, структуру, скорость загрузки, удобство на мобильных, поведение пользователей. В интерфейсе Яндекс.Вебмастера и Google Search Console нет ни одного показателя, который различал бы статику и CMS.

Влияние есть, но косвенное, и работает в обе стороны.

• В плюс. Если движок настроен плохо — тяжёлая тема, полсотни плагинов, нет кэша — статический сайт выигрывает за счёт скорости отдачи и чистой разметки. Скорость входит в оценку качества и заметно влияет на поведенческие показатели: с медленной страницы уходят, не дождавшись.
• В минус. Если из-за неудобства правок сайт не развивается — не появляются новые страницы под спрос, не обновляются старые тексты, не растёт структура — он проигрывает конкурентам, которые публикуют регулярно. Поиск любит живые сайты, и через год-два разрыв становится решающим.

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

Что на статике обязательно настроить вручную

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

Элемент	Как решается на статике	Что будет, если пропустить
sitemap.xml	Пишется руками или генерируется скриптом при сборке	Новые страницы попадают в индекс медленнее
robots.txt	Обычный файл в корне, указать хост и ссылку на карту	В индекс попадают служебные и тестовые файлы
Title и description	Прописываются в каждом файле отдельно	Дубли заголовков, плохие сниппеты, потеря кликов
Заголовок H1	Один на страницу, вручную	Размытая релевантность страницы
Канонические адреса	Тег link rel canonical в head каждой страницы	Дубли при доступности страницы по нескольким адресам
Один вариант адреса	Редирект с www на без www, с http на https, со слеша на без слеша	Склейка не происходит, вес распыляется
301-редиректы	Правила на уровне сервера (.htaccess или конфиг nginx)	При смене адреса страница теряет позиции
Страница 404	Отдельный файл плюс директива сервера, обязательно с кодом 404	Несуществующие адреса отдают код 200 и засоряют индекс
Микроразметка	JSON-LD вставляется в код страницы вручную	Нет расширенных сниппетов: организация, товар, вопросы
Open Graph	Метатеги в head	Некрасивые превью при репостах
Аналитика	Счётчики Метрики и Analytics в шаблон каждой страницы	Нет данных о трафике и заявках
Отслеживание заявок	Цели на отправку формы, подмена номера при необходимости	Невозможно оценить окупаемость продвижения
HTTPS	Сертификат на хостинге плюс редирект	Предупреждение браузера, падение доверия
Резервная копия	Репозиторий или регулярный архив	Потеря сайта при сбое хостинга

Отдельно про 404: на статике эту ошибку допускают чаще всего. Файл с красивой страницей ошибки создают, а директиву серверу не прописывают — и любой битый адрес отдаёт либо стандартную страницу хостера, либо, что хуже, код 200.

Генераторы статических сайтов: компромисс, который часто и нужен

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

Если нужна помощь по теме — курсы SEO-оптимизации.

Что это даёт:

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

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

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

Если нужны детали, смотрите «Как SEO оптимизировать сайт».

Кому подходит чистый HTML, а кому нет

Тип проекта	Статика	Почему
Одностраничный лендинг	Подходит	Содержимое меняется редко, важна скорость и уникальная вёрстка
Сайт-визитка на 3-7 страниц	Подходит	Объём правок минимален, структура не растёт
Техническая документация	Подходит	Удобно вести в файлах, собирать генератором, держать версии
Промо-страница акции или мероприятия	Подходит	Живёт ограниченный срок, нагрузка может быть пиковой
Проект с высокой нагрузкой	Подходит	Статика выдерживает всплески трафика без падения сервера
Сайт с редко меняющимся содержимым	Скорее подходит	Правки раз в квартал не создают нагрузки на бюджет
Блог, новостной раздел	Не подходит	Регулярные публикации, ленты, рубрики, метки
Интернет-магазин	Не подходит	Каталог, остатки, цены, корзина, оплата, фильтры
Сайт услуг с растущей структурой	Не подходит	Новые страницы под запросы нужны постоянно, иначе нет роста
Многорегиональный сайт	Не подходит	Десятки почти одинаковых страниц, которые надо генерировать
Портал, площадка с пользователями	Не подходит	Регистрация, личные кабинеты, пользовательский контент

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

Как переехать со статики на движок без потери позиций

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

Шаг	Действие	Как проверить
1	Выгрузить полный список текущих адресов и их метатегов	Краулер по сайту плюс список страниц в поиске из Вебмастера
2	Зафиксировать текущие позиции и трафик по разделам	Отчёты Метрики и Вебмастера за 3 месяца до переезда
3	Сохранить адреса один в один, где это возможно	Сравнение старого и нового списка адресов
4	Для изменённых адресов настроить постраничные 301	Проверка кода ответа по каждому старому адресу
5	Перенести title, description, H1, тексты без сокращений	Сверка выгрузок до и после
6	Перенести микроразметку и канонические адреса	Валидаторы структурированных данных
7	Собрать сайт на тестовом домене, закрытом от индексации	robots.txt с запретом плюс проверка, что тест не в индексе
8	Проверить скорость новой версии до запуска	Сравнение с показателями статики, донастройка кэша
9	Переключить домен, снять запрет индексации	Открыть robots.txt на боевом домене и убедиться, что запрета нет
10	Отправить обновлённый sitemap и страницы на переобход	Разделы переобхода в Вебмастере и Search Console
11	Следить за индексацией и ошибками 2-4 недели	Отчёты по страницам в поиске и по кодам ответа
12	Сверить трафик по разделам через месяц	Сравнение с зафиксированной базой из шага 2

Главная ошибка при таких переездах — считать, что редиректы можно настроить потом. Старые адреса начинают отдавать 404 в первый же день, робот их переобходит, страницы выпадают из поиска, и возвращать их приходится неделями. Правила редиректов должны быть готовы и проверены до переключения.

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

Как решить, что выбрать

Ответьте на четыре вопроса, и выбор станет очевидным.

• Сколько правок в месяц вы планируете? Одна-две — статика нормальна. Еженедельные — нужен движок.
• Будет ли расти структура? Если продвижение предполагает новые страницы под запросы, статика будет тормозить работу.
• Кто будет вести сайт? Есть технический человек — можно смотреть в сторону генератора. Ведёт менеджер — нужна админка.
• Нужны ли функции? Поиск, фильтры, кабинет, оплата — вопрос закрыт, только движок.

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

Частые вопросы

Понижает ли поиск сайты на чистом HTML?
Нет. Робот получает готовый HTML и не знает, чем он сгенерирован. Оценивается содержимое страницы, её техническое состояние и поведение пользователей. Ни в Вебмастере, ни в Search Console нет фактора «сайт на CMS».

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

Как принимать заявки без базы данных?
Через внешний обработчик: сервис форм, серверная функция у хостинг-провайдера, готовый виджет. Заявка уходит на почту или в CRM. Обязательно настройте защиту от спама и цель в аналитике на успешную отправку, иначе заявки будут теряться незаметно.

Что дешевле в итоге?
Разработка простого статического сайта обычно дешевле, хостинг тоже. Но каждая правка контента оплачивается отдельно. Если правок больше нескольких в месяц, экономия исчезает за первый год. Считайте не стоимость запуска, а стоимость владения на два-три года.

Сайт на статике не открывался год, всё ли с ним в порядке?
С файлами почти наверняка да — им нечему ломаться. Проверьте другое: не истёк ли срок домена и сертификата, работает ли редирект на https, отдаёт ли несуществующий адрес код 404, живы ли счётчики и обработчик формы. Именно внешние сервисы отваливаются чаще всего.

Разбираю продвижение по шагам — в своём курсе:

8:14

Коротко

• Статический сайт отдаёт готовый файл без базы и админки — отсюда максимальная скорость, отсутствие уязвимостей движка, дешёвый хостинг и независимость от обновлений.
• Плата за это — каждая правка через разработчика, нет удобного добавления материалов, поиска, фильтров и ролей, а масштабирование за сотню страниц становится мучением.
• На позиции сама технология не влияет: поиск оценивает страницу. Статика выигрывает косвенно за счёт скорости и проигрывает, когда из-за дорогих правок сайт перестаёт развиваться.
• На статике вручную настраиваются sitemap, robots, метатеги, канонические адреса, микроразметка, 301-редиректы, корректная 404 и аналитика — без этого индексация просядет.
• Чистый HTML оправдан для лендинга, визитки, документации и проектов с редко меняющимся содержимым; для блога, магазина и растущего сайта услуг нужен движок, а генератор статических сайтов — разумный компромисс.

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