Как сделать пароль на сайте в 2026: закрыть сайт или страницу

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

Сначала решите, что именно вы закрываете

От ответа зависит способ: защита черновика и защита личных данных клиентов делаются по-разному.

• Черновик, тестовая версия, страница для показа одному клиенту: хватит пароля на стороне хостинга.
• Раздел, который не должен попасть в поиск: тот же пароль на хостинге плюс запрет индексации в robots.txt и метатег noindex.
• Платные материалы, личный кабинет, персональные данные людей: нужен полноценный вход по логину и паролю с базой пользователей.
• Страница-сюрприз или квест, где ничего ценного нет: подойдёт даже самый слабый вариант.

Уровень 1: пароль на стороне хостинга

Это базовая HTTP-аутентификация (Basic). Работает так: браузер показывает системное окно с полями логина и пароля, а сервер до правильного ответа не отдаёт ни байта содержимого. Ключевое отличие от всех вариантов «пароль внутри страницы»: проверку делает сервер, поэтому в коде страницы подсматривать нечего.

Самый быстрый путь: панель управления хостингом. Раздел обычно называется «Защита директории паролем», «Ограничение доступа» или «Password protected directories».

1. Откройте панель хостинга и найдите раздел защиты директорий.
2. Выберите папку: корневую, чтобы закрыть весь сайт, или, например, /admin, чтобы закрыть только служебный раздел.
3. Задайте логин и пароль. Пароль лучше сгенерировать, а не придумывать.
4. Сохраните настройку и подождите минуту, пока сервер перечитает конфигурацию.
5. Проверьте результат в приватном окне браузера: должно появиться окно ввода логина.

Если панель такого не умеет, то же самое делается двумя файлами. На Apache в закрываемую папку кладётся файл .htaccess:

AuthType Basic
AuthName "Zakrytyy razdel"
AuthUserFile /home/user/site/.htpasswd
Require valid-user

Второй файл, .htpasswd, хранит логины и хеши паролей. Строку для него создаёт команда htpasswd -c /home/user/site/.htpasswd anna или генератор в панели хостинга. Путь в AuthUserFile пишется абсолютный, а сам .htpasswd лучше положить выше папки сайта, чтобы он не открывался по прямой ссылке.

На nginx файлы .htaccess не читаются, настройка живёт в конфиге сервера:

location / {
    auth_basic "Zakrytyy razdel";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

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

На готовых платформах кнопка уже есть. В Tilda весь сайт закрывается в настройках сайта, раздел «Ограничить доступ», где задаются логин и пароль; отдельная страница закрывается в её настройках, вкладка «Дополнительно», поле «Пароль на страницу» (инструкция Tilda). Там же можно пустить на сайт только определённые IP-адреса. Про саму сборку на этой платформе есть подробный разбор Тильды.

У хостингов статики правила разные. Netlify даёт пароль на сайт и Basic Auth через файл _headers, но для аккаунтов, созданных после 4 сентября 2025 года, это функция платных планов (документация Netlify). А GitHub Pages пароли не поддерживает вовсе: серверного кода там нет, .htaccess не читается, приватная публикация возможна только в GitHub Enterprise Cloud (обсуждение в сообществе GitHub).

Прежде чем отправлять клиенту ссылку на закрытый черновик, откройте её в приватном окне и с телефона. Половина историй «а пароль почему-то не спросили» это кэш браузера, в котором вы уже вошли.

По теме: Как сделать сайт с таблицей в 2026: вставить таблицу и взять данные

Уровень 2: пароль внутри кода страницы, и почему это не защита

Второй по популярности способ: небольшой скрипт на странице, который сравнивает введённое слово со строкой в коде и показывает скрытый блок. Выглядит убедительно, но защитой не является.

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

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

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

Уровень 3: настоящий вход по логину и паролю

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

Главное правило: пароли не хранят. Хранят их хеши, то есть необратимые отпечатки. Даже если базу украдут, восстановить из хеша исходный пароль долго и дорого. Актуальные рекомендации собраны в OWASP Password Storage Cheat Sheet, и на 2026 год порядок такой:

• Argon2id: первый выбор, минимальные параметры по OWASP это 19 МиБ памяти, 2 итерации и степень параллелизма 1.
• scrypt: вариант, когда Argon2id недоступен, минимальный параметр стоимости 2^17, размер блока 8 и параллелизм 1.
• bcrypt: для старых систем, work factor от 10 и ограничение длины пароля 72 байта.
• PBKDF2: когда требуется сертификация FIPS-140, минимум 600 000 итераций с HMAC-SHA-256.

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

Писать такую систему с нуля не стоит, и дело не в самом хешировании, а в объёме сопутствующего:

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

Проще взять готовый сервис аутентификации. У Supabase бесплатный план включает до 50 000 активных пользователей в месяц, Pro стоит от $25 в месяц, при этом бесплатные проекты засыпают после недели простоя. У Clerk бесплатный план тоже до 50 000 пользователей в месяц (считаются те, кто вернулся позже чем через сутки после регистрации), Pro стоит $25 в месяц. Оба сервиса зарубежные: интерфейс работает, а оплатить платный план российской картой не выйдет, это стоит учесть заранее.

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

По теме: Как сделать папки сайта в 2026: структура файлов и адреса страниц

Как поручить защиту ИИ-ассистенту

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

1. Скажите, что закрываете и от кого: «закрыть весь сайт на время разработки» и «сделать вход для 200 покупателей курса» решаются разными способами.
2. Назовите хостинг и стек: Apache, nginx, Tilda, Netlify. Без этого ассистент выдаст абстрактный код, который у вас не заработает.
3. Потребуйте серверную проверку и явно запретите пароль внутри JavaScript или HTML.
4. Запретите записывать пароли, ключи и токены в код и в репозиторий: им место в переменных окружения или в настройках хостинга.
5. Для входа пользователей потребуйте хеширование готовой библиотекой с Argon2id или bcrypt и попросите показать, где лежат хеши.
6. Попросите перечислить, что осталось незакрытым: ограничение попыток входа, HTTPS, восстановление пароля, выход из сессии.

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

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

Можно ли поставить пароль на одну страницу, а не на весь сайт?

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

Попадёт ли закрытая паролем страница в поиск?

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

Хватит ли запрета индексации вместо пароля?

Нет. Файл robots.txt и метатег noindex управляют поисковыми роботами, а не доступом: ссылку по-прежнему откроет любой, кому она попала. Если содержимое не для чужих глаз, нужен именно пароль.

Что делать, если пароль от базовой аутентификации забыт?

Восстановить его нельзя, в .htpasswd лежит хеш. Создайте пользователя заново той же командой или через панель хостинга, а старую строку удалите.

Насколько такой пароль устойчив к подбору?

Число попыток базовая аутентификация не ограничивает, поэтому всё решает длина: 16 случайных символов подобрать нереально, а пару вида admin и 1234 сканер переберёт быстро.