GitHub Pages — бесплатный хостинг статических сайтов прямо из GitHub

GitHub Pages — сервис GitHub для публикации статических сайтов прямо из репозитория. Он принимает HTML, CSS и JavaScript, при необходимости запускает сборку и публикует результат на домене github.io или собственном домене.

Требования и примеры сверены 3 октября 2026 года. HTML и структура YAML проверены локально; Pages deploy, DNS и выпуск сертификата при подготовке не выполнялись. Настройка публикации в собственном репозитории может запустить выпуск сайта.

Что такое GitHub Pages

GitHub Pages подходит для документации, портфолио, блогов, демонстраций и других сайтов без серверной логики. Серверный код на PHP, Python или Node.js не выполняется: результатом публикации должны быть статические файлы.

GitHub Pages доступен в публичных репозиториях с GitHub Free и GitHub Free для организаций. Публикация из публичных и приватных репозиториев доступна на GitHub Pro, GitHub Team, GitHub Enterprise Cloud и GitHub Enterprise Server. По умолчанию сайт публичен даже при приватном исходном репозитории. Для закрытой публикации нужны отдельные поддерживаемые условия Enterprise и настройка доступа; приватность исходника сама по себе её не включает. Не помещайте в публикуемые файлы ключи, пароли и другие закрытые данные.

Основные возможности

Подключение и выбор источника публикации

Для настройки Pages нужны права администратора или сопровождающего репозитория (maintainer). Опубликовать сайт можно одним из двух способов.

• Deploy from a branch — GitHub публикует изменения из выбранной ветки. В качестве исходной папки можно выбрать корень репозитория (/) или каталог /docs.
• GitHub Actions — собственный workflow GitHub Actions (сценарий автоматизации) сначала собирает сайт, а затем передаёт готовые статические файлы Pages.

Если отдельная сборка не нужна, GitHub рекомендует публикацию из ветки. Workflow подходит, когда требуется сборка не на Jekyll или когда готовые файлы не должны храниться в отдельной ветке.

Пользовательские и проектные сайты

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

Для работы нужен аккаунт GitHub и публичный репозиторий либо тариф, поддерживающий Pages для приватных репозиториев.

Создайте репозиторий

1. На GitHub выберите New repository.
2. Укажите имя username.github.io, заменив username точным именем аккаунта.
3. Выберите видимость репозитория.
4. Создайте репозиторий.

Добавьте главную страницу

Создайте в корне файл index.html:

<!doctype html>
<html lang='ru'>
<head>
  <meta charset='utf-8'>
  <meta name='viewport' content='width=device-width, initial-scale=1'>
  <title>Мой первый сайт</title>
  <style>
    body {
      max-width: 800px;
      margin: 0 auto;
      padding: 2rem;
      font-family: system-ui, sans-serif;
      background: #f8f9fa;
      color: #24292f;
    }
    .card {
      padding: 1.5rem;
      border-radius: 8px;
      background: white;
      box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
    }
  </style>
</head>
<body>
  <h1>Привет, мир!</h1>
  <div class='card'>
    <p>Это мой первый сайт на GitHub Pages.</p>
  </div>
</body>
</html>

Зафиксируйте изменение кнопкой Commit changes.

Включите публикацию из ветки

1. Откройте Settings → Pages.
2. В блоке Build and deployment выберите Source → Deploy from a branch.
3. Выберите фактическую основную ветку, например main, и папку / (root).
4. Нажмите Save.

Проверьте результат

Откройте страницу Settings → Pages или запуск во вкладке Actions. После успешного развёртывания GitHub покажет адрес сайта. Перейдите по нему и убедитесь, что отображается содержимое index.html.

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

Публикация проектного сайта

Для публикации из ветки GitHub поддерживает две исходные папки:

• / (root) — корень выбранной ветки;
• /docs — папка docs в выбранной ветке.

В Settings → Pages → Source выберите Deploy from a branch, затем ветку и нужную папку. Веткой может быть main, gh-pages или любая другая существующая ветка.

Если проект нужно сначала собрать, выберите GitHub Actions. Этот вариант подходит, когда исходные файлы и готовый сайт различаются или используется сборка, отличная от встроенной сборки Jekyll.

Публикация через GitHub Actions

В Settings → Pages → Source выберите GitHub Actions. GitHub предложит готовые шаблоны, но workflow можно создать вручную.

Статический сайт без отдельной сборки

Для этого способа положите публикуемый index.html и его ресурсы в отдельную папку site. Корневой пример выше относится к публикации из ветки; здесь загрузится только site, без остальных документов и настроек репозитория.

Создайте .github/workflows/deploy.yml:

name: Deploy static site to GitHub Pages

on:
  push:
    branches: [main] # Замените main на имя основной ветки репозитория.
  workflow_dispatch:

permissions:
  contents: read # Разрешает читать содержимое репозитория.
  pages: write # Разрешает публикацию GitHub Pages.
  id-token: write # Нужно для подтверждения публикации Pages.

concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7

      - name: Configure Pages
        uses: actions/configure-pages@983d7736d9b0ae728b81ab479565c72886d7745b # v5

      - name: Upload site
        uses: actions/upload-pages-artifact@7b1f4a764d45c48632c6b24a0339c27f5614fb0b # v4
        with:
          path: ./site

      - name: Deploy
        id: deployment
        uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4

В примере main — условное имя основной ветки. Версии actions и commit SHA сверены 3 октября 2026 года; основные требования описаны в документации Pages workflows. Перед будущим обновлением проверяйте компоненты заново.

После отправки изменений откройте запуск во вкладке Actions. Успешный job deploy и URL в окружении github-pages подтверждают публикацию.

Если окружение github-pages ещё не существует, GitHub создаст его автоматически. Для него рекомендуется добавить правило защиты развёртывания, разрешающее публикацию только из основной ветки.

Сайт со сборкой

Если проект нужно собрать, подготавливайте поддерживаемую им версию среды, затем добавьте штатные команды установки и сборки между checkout и загрузкой артефакта. Следующий фрагмент показывает эти шаги внутри полного workflow выше; самостоятельно он не запускается. Для Node-проекта с package-lock.json пример может выглядеть так:

- name: Install dependencies
  run: npm ci

- name: Build site
  run: npm run build

- name: Upload site
  uses: actions/upload-pages-artifact@7b1f4a764d45c48632c6b24a0339c27f5614fb0b # v4
  with:
    path: ./dist

Замените ./dist на каталог с готовыми статическими файлами. Если сборка и развёртывание находятся в разных jobs, job развёртывания должен содержать needs: build. Для него также нужны разрешения pages: write и id-token: write и окружение github-pages.

Проверка результата

• При публикации из ветки проверьте выбранные ветку и папку в Settings → Pages.
• При публикации через Actions проверьте успешное выполнение шагов сборки, загрузки артефакта и deploy.
• Откройте URL, который GitHub показывает в Pages или в окружении github-pages, и проверьте главную страницу, навигацию и статические файлы.
• Для проектного сайта отдельно проверьте ссылки на CSS, изображения и другие ресурсы с учётом префикса /repository-name/.

Подключение собственного домена

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

Укажите домен в GitHub

1. Откройте Settings → Pages.
2. В поле Custom domain введите домен и нажмите Save.
3. После выпуска сертификата включите Enforce HTTPS. Переключатель может появиться не сразу.

При публикации из ветки сохранение домена создаёт коммит с файлом CNAME в корне исходной ветки. При публикации через собственный workflow файл CNAME не создаётся, а существующий файл игнорируется и не требуется.

Настройте DNS

Для корневого домена, например example.com, используйте ALIAS, ANAME или A-записи. При варианте с A-записями GitHub указывает следующие адреса:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Для поддомена, например www.example.com, создайте CNAME-запись, которая указывает прямо на домен пользователя или организации без имени репозитория:

www.example.com.  CNAME  username.github.io.

Избегайте wildcard-записей вида *.example.com: GitHub предупреждает о риске перехвата поддоменов. DNS-изменения могут распространяться до 24 часов. Возможность включить Enforce HTTPS также может появиться в течение 24 часов.

Тарифы и лимиты

Лимиты сверены с официальной документацией 3 октября 2026 года.

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

Полезные сценарии

Портфолио

Задача: дать ссылку на личный сайт с проектами и контактами. Условие: создайте репозиторий username.github.io и положите в исходную папку index.html. Действия: включите публикацию из выбранной ветки и корня репозитория. Проверяемый результат: по адресу https://username.github.io открывается содержимое главной страницы. Ограничение: сценарий не подходит сайту, которому нужна серверная логика.

Документация проекта

Задача: опубликовать документацию отдельно от README. Условие: храните готовые файлы в /docs или собирайте их workflow. Действия: выберите ветку и /docs либо загрузите результат сборки как Pages artifact. Проверяемый результат: проектный адрес открывает документацию, а навигация и ссылки работают. Ограничение: при выборе /docs её удаление из исходной ветки вызывает ошибку сборки.

Блог на генераторе статических сайтов

Задача: публиковать записи из исходных файлов без серверной части. Условие: генератор должен создавать готовые статические файлы. Действия: выполните сборку в workflow и загрузите каталог результата через actions/upload-pages-artifact. Проверяемый результат: успешный запуск Actions и появление обновлённой записи на сайте. Ограничение: динамические серверные функции и закрытые данные Pages не обрабатывает.

Демонстрация интерфейса

Задача: передать заказчику или команде ссылку на рабочий прототип. Условие: прототип состоит из HTML, CSS и клиентского JavaScript, не требует закрытых данных и соответствует ограничениям использования Pages. Действия: опубликуйте файлы из ветки или через workflow. Проверяемый результат: интерфейс открывается по публичному URL и работает в браузере. Ограничение: сценарий не подходит для серверных API, авторизации и передачи паролей или платёжных данных.

Чеклист быстрой проверки

Частые проблемы

Сайт возвращает 404

Проверьте выбранную ветку и папку, наличие index.html и журнал Actions. Имена файлов чувствительны к регистру: About.html и about.html считаются разными путями.

Не загружаются CSS и изображения

У проектного сайта адрес содержит /repository-name/. Проверьте, что пути к ресурсам учитывают этот префикс. Используйте относительные пути или задайте base либо baseURL в настройках генератора.

Папка /docs перестала публиковаться

Если /docs выбрана источником, её удаление из выбранной ветки вызывает ошибку сборки Pages. Верните папку или измените источник в Settings → Pages.

Изменения, отправленные workflow, не запускают сборку из ветки

Коммиты, созданные GitHub Actions с GITHUB_TOKEN, не запускают новую сборку Pages из ветки. Для автоматизированной сборки используйте собственный Pages workflow и загрузку артефакта.

Собственный домен не работает

Проверьте значение Custom domain, DNS-записи и отсутствие wildcard-записей. Распространение DNS и появление переключателя Enforce HTTPS могут занять до 24 часов.

Официальные источники

• Что такое GitHub Pages
• Настройка источника публикации
• Собственные workflow для GitHub Pages
• Настройка собственного домена
• Лимиты GitHub Pages

Следующий шаг

Astro: фреймворк для молниеносных сайтов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov