GitHub Pagesとは｜使い方・公開3通り・独自ドメインと404の直し方

GitHub Pages は、リポジトリにあるファイルを「ブランチからそのまま」か「GitHub Actions でビルドして」配る仕組みです。どちらの道でも、最後は github.io の URL で公開されます。

flowchart TD
    A[リポジトリ<br>HTML・CSS・JS] --> B{公開の方法}
    B --> C[ブランチから<br>/ か /docs を配る]
    B --> D[GitHub Actions で<br>ビルドして配る]
    C --> E[ユーザー名.github.io<br>/リポジトリ名/ で公開]
    D --> E

よく調べられることを先にまとめます。

確認環境：Ubuntu 24.04.4・Node.js 22.22.2・npm 10.9.7・Git 2.43.0・GNU tar 1.35。create-vite 9.3.1 で作ったサイトを Vite 8.3.5 で base を /・/my-site/・./ の3通りにビルドし、Astro 7.4.1 のサイトも base: '/my-site' でビルドしました。できたファイルを、GitHub Pages のプロジェクトサイトと同じ URL の形（/my-site/ の下）で配る手元の静的サーバー（Python 3.11.15）に置き、Chromium 141.0.7390.37（playwright-core 1.56.0）で開いて、読み込みの失敗・画面の中身・リンク先を記録しました。workflow は @action-validator/cli 0.6.0 で文法を検証し、actions/upload-pages-artifact v5.0.0 と同じ tar のコマンドを手元で実行して、成果物に入るファイルを確かめました。エラー文は actions/deploy-pages v5.0.1・actions/configure-pages v6.0.0 のソースから引用しています。公開の手順・制限・独自ドメイン・HTTPS・Jekyll は docs.github.com、Hugo の workflow は gohugo.io と hugoDocs のソース、Netlify・Vercel・Cloudflare Pages は各公式の料金・制限のページで確かめました（確認日 2026年10月23日）。

GitHub Pagesとは（できること・無料か・URL）

この節では、GitHub Pages で何が公開できて、何ができないのか、お金がかかるのかが分かります。

GitHub Pages は、GitHub のリポジトリに置いた HTML・CSS・JavaScript のファイルを、Web サイトとして公開する GitHub の機能です。 公式ドキュメントは、ファイルを「必要ならビルドの処理に通してから」公開すると説明しています。ビルドの処理は、ブランチから公開するときは Jekyll（Ruby 製の静的サイトジェネレーター）、GitHub Actions で公開するときは自分で書いた workflow です。

使われている例は、ライブラリのドキュメント、個人のポートフォリオ、技術ブログ、イベントの告知ページなどです。フォームの送信先やログインが要る部分は、外部のサービスや API を JavaScript から呼んで補います。

料金（無料で使える条件）

公開リポジトリなら無料です（2026年10月23日時点）。 非公開（private）のリポジトリから公開したい場合は Pro・Team 以上が要ります。ただし、非公開のリポジトリから公開しても、できたサイトはインターネットに公開されます。閲覧できる人をリポジトリの読み取り権限を持つ人に限る「private publishing」は、組織が GitHub Enterprise Cloud を使っている場合だけの機能です。GitHub の料金ページでは、Team が1ユーザーあたり月 4 ドル（最初の12か月）、Enterprise が月 21 ドルからと書かれています。

公式ドキュメントは、閲覧者の IP アドレスがセキュリティのために記録・保存されることも書いています（GitHub にログインしているかどうかに関わらず）。

ユーザーサイトとプロジェクトサイトの違い

この節では、公開される URL が何で決まるかと、2種類のサイトの違いが分かります。この違いが、あとで出てくる「CSS が読めない」の原因の大半です。

プロジェクトサイトは、ユーザーサイトと同じドメインの「下のフォルダ」に置かれます。ページの中で /assets/app.css のように / から始まるパスを書くと、ブラウザは https://ユーザー名.github.io/assets/app.css（ユーザーサイトの側）を取りに行きます。プロジェクトサイトのファイルは /リポジトリ名/assets/app.css にあるので、見つからずに 404 になります。

flowchart TD
    A[ページの URL は<br>my-site の下] --> B{CSS の書き方}
    B --> C[先頭が / の<br>assets/app.css]
    B --> D[base つきの<br>my-site/assets/app.css]
    C --> E[ユーザーサイト側を<br>探して 404]
    D --> F[読み込める]

独自ドメイン（www.example.com など）を設定すると、プロジェクトサイトでもサイトの一番上が / になります。このときは base を / に戻します。

GitHub Pagesの使い方（HTMLを公開する最短手順）

この節では、ビルドの無い HTML のサイトを、ブランチから公開するまでの手順が分かります。

ターミナルで行う部分は次のとおりです。

mkdir my-site && cd my-site
git init -b main
echo '<!doctype html><title>Hello</title><h1>Hello GitHub Pages</h1>' > index.html
git add index.html
git commit -m "first page"
git remote add origin https://github.com/ユーザー名/my-site.git
git push -u origin main

公式ドキュメントは、push してから公開に反映されるまで最大10分かかることがあると書いています。

公開方法3通り（ブランチ・/docs・GitHub Actions）の選び方

この節では、3つの公開方法の違いと、自分のサイトにどれが合うかが分かります。

公式ドキュメントは「GitHub Actions is now the recommended approach」として、GitHub Actions での公開をすすめています。 ブランチから公開する方法も引き続き使えます。

gh-pagesブランチに公開物だけを置く形

ビルドした結果だけを別のブランチに置く方法は、Actions が使えなかった頃からある形です。Git 2.42 以降なら git worktree add --orphan で、履歴を持たない gh-pages ブランチを作業フォルダごと作れます。手元のリポジトリ（push 先は手元の bare リポジトリ）で実行した結果です。

npm run build                                   # dist/ ができる
git worktree add --orphan -b gh-pages ../pages-wt
cp -r dist/. ../pages-wt/
touch ../pages-wt/.nojekyll                     # Jekyll を通さない
cd ../pages-wt && git add -A && git commit -m "deploy"
git push origin gh-pages

Preparing worktree (new branch 'gh-pages')
To ../remote.git
 * [new branch]      gh-pages -> gh-pages

$ git ls-tree -r --name-only gh-pages
.nojekyll
assets/index-BcJu40rv.js
assets/index-DjPfO8yo.css
bg.svg
data.json
favicon.svg
index.html

gh-pages ブランチには公開物だけが入り、main のソースとは履歴が分かれます。Settings → Pages で gh-pages の / (root) を選ぶと公開されます。公式ドキュメントは、GITHUB_TOKEN を使う workflow から push したコミットでは Pages のビルドが起きないと書いています。Actions の中でこの形にするより、次の節の公式の Actions を使う方が手順が少なく済みます。ブランチの仕組みは、関連記事「ブランチとは｜Gitの作成・切り替え・マージと正体を実例で解説」で扱っています。

GitHub Actionsで公開する（Vite・Astro・Hugoのworkflow）

この節では、静的サイトジェネレーターのビルド結果を GitHub Actions で公開する workflow が、文法を検証した実物で分かります。

最初に、Settings → Pages の Source を GitHub Actions に変えます。workflow は次の3つの公式のアクションを順に使います（版は2026年10月23日時点の最新のタグ）。

Viteのworkflow（baseを自動で合わせる）

vite.config.js の base を環境変数から読むようにしておきます。

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  base: process.env.BASE ?? '/',
})

.github/workflows/deploy.yml です。configure-pages が出力する base_path（プロジェクトサイトなら /リポジトリ名、ユーザーサイトや独自ドメインなら空）を BASE に渡すので、リポジトリ名や独自ドメインを変えても workflow を直さずに済みます。

name: Deploy Vite to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: lts/*
          cache: npm
      - id: pages
        uses: actions/configure-pages@v6
      - run: npm ci
      - run: npm run build
        env:
          BASE: ${{ steps.pages.outputs.base_path }}/
      - uses: actions/upload-pages-artifact@v5
        with:
          path: ./dist

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v5

Vite の公式ドキュメントの例は、build と deploy を1つのジョブにまとめた形で、base は '/リポジトリ名/' と直接書く形です。どちらでも動きます。vite.config.js の書き方は、関連記事「vite.configの書き方｜用途別コピペ一覧とVite 8の変更点」で扱っています。

Astroのworkflow（withastro/action）

Astro は、ビルドからアップロードまでを1つにまとめた公式のアクション withastro/action があります。astro.config.mjs に site と base を書きます。

// astro.config.mjs
import { defineConfig } from 'astro/config'

export default defineConfig({
  site: 'https://ユーザー名.github.io',
  base: '/my-site',
})

name: Deploy Astro to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: withastro/action@v6

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v5

withastro/action v6.1.3 の入力は、node-version（既定 24）・package-manager（空ならロックファイルから自動で判定）・path（既定 .）・build-cmd・out-dir（既定 dist）などです。中では actions/upload-pages-artifact の v5 を呼んでいます。Astro の公式ドキュメントは、パッケージマネージャーを判定するためにロックファイル（package-lock.json など）をコミットするよう書いています。Astro の基本は、関連記事「Astro入門｜静的サイトとアイランドのJS量を実測」で扱っています。

Hugoのworkflow

Hugo の公式ドキュメントの workflow から、Dart Sass・Go・Node.js の準備を外して短くした形です。--baseURL に configure-pages の base_url を渡すので、hugo.toml の baseURL を GitHub Pages 用に書き換えずに済みます。

name: Deploy Hugo to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

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

env:
  HUGO_VERSION: 0.168.0

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          submodules: recursive
          fetch-depth: 0
      - id: pages
        uses: actions/configure-pages@v6
      - name: Install Hugo
        run: |
          curl -sfL --output-dir "${{ runner.temp }}" -O "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-amd64.tar.gz"
          mkdir -p "${HOME}/.local/hugo"
          tar -C "${HOME}/.local/hugo" -xf "${{ runner.temp }}/hugo_${HUGO_VERSION}_linux-amd64.tar.gz"
          echo "${HOME}/.local/hugo" >> "${GITHUB_PATH}"
      - name: Build
        run: hugo build --gc --minify --baseURL "${{ steps.pages.outputs.base_url }}/"
      - uses: actions/upload-pages-artifact@v5
        with:
          path: ./public

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v5

テーマを Git のサブモジュールで入れている場合が多いので、submodules: recursive を付けています。Hugo の公式の workflow には、ほかに Hugo のキャッシュの保存と、TZ（ビルドのタイムゾーン）の設定があります。

workflowの文法を検証した結果

上の3つの workflow と、わざと間違えた workflow を、JSON スキーマで検証する @action-validator/cli 0.6.0 にかけました。3つはエラー0（終了コード 0）でした。間違えた方の中身と結果です。

# broken.yml（permissions を permission と書き、runs-on を忘れた）
name: broken
on:
  push:
    branches: [main]
permission:
  pages: write
jobs:
  deploy:
    steps:
      - uses: actions/deploy-pages@v5

{
  "code": "required",
  "path": "/jobs/deploy/runs-on",
  "title": "This property is required"
}
…
{
  "code": "properties",
  "detail": "Additional property 'permission' is not allowed",
  "path": "",
  "title": "Property conditions are not met"
}
exit=1

キーの書き間違い（permission）と、必須のキーの抜け（runs-on）が見つかりました。push する前にこうした検証をかけると、Actions のタブで失敗してから直す回数が減ります。GitHub Actions の基本は、関連記事「CI/CDとは｜GitHub Actionsで最初のパイプラインを作るまで」で扱っています。

成果物に入らないファイル（.で始まるファイル）

actions/upload-pages-artifact は、中で tar を実行して公開するフォルダをまとめます。v5.0.0 の action.yml の Linux 用のコマンドを、そのまま手元で実行しました。公開フォルダには .nojekyll・.well-known/security.txt・CNAME・シンボリックリンク（robots-link.txt）を置きました。

tar --dereference --hard-dereference --directory dist -cvf artifact.tar \
  --exclude=.git --exclude=.github --exclude='.[^/]*' .

. で始まるファイルとフォルダは、既定では成果物に入りません。 .well-known/ を公開したいときは、with: に include-hidden-files: true を足します。シンボリックリンクは --dereference で中身のファイルになって入りました。deploy-pages のソースには「Please ensure the content does not contain any hard links, symlinks and total size is less than 10GB.」というエラー文があり、公式ドキュメントも成果物の tar は 10GB 未満でリンクを含まないことを条件にしています。

CSSが読めない・真っ白になる原因（baseのパスの違い）

この節では、プロジェクトサイトでよく起きる「HTML は出るのに CSS・JS が読めない」の仕組みを、ビルドしてブラウザで開いた実物で確かめられます。

Vite で作った小さなページを、base を3通りにしてビルドし、/my-site/ の下に置いて Chromium で開きました。ページは、CSS で背景を青くし、JavaScript で見出しと結果の行を描き、public/data.json を2通りの書き方で fetch します。

// src/main.js（抜粋）
const base = import.meta.env.BASE_URL
show('abs', '/data.json')          // 先頭が / の文字列
show('rel', `${base}data.json`)    // BASE_URL を付ける

ビルドされたHTMLの違い

<!-- base: '/'（既定） -->
<script type="module" crossorigin src="/assets/index-BYSJLi2y.js"></script>
<link rel="stylesheet" crossorigin href="/assets/index-C3YTNyfo.css">

<!-- base: '/my-site/' -->
<script type="module" crossorigin src="/my-site/assets/index-BcJu40rv.js"></script>
<link rel="stylesheet" crossorigin href="/my-site/assets/index-DjPfO8yo.css">

<!-- base: './' -->
<script type="module" crossorigin src="./assets/index-7wVU5SeL.js"></script>
<link rel="stylesheet" crossorigin href="./assets/index-Di2YU0Mv.css">

CSS の中の url('/bg.svg') も、/my-site/ では url(/my-site/bg.svg)、./ では url(../bg.svg) に書き換わりました。一方、JavaScript の中の '/data.json' という文字列は、どの base でも書き換わりませんでした。

Chromiumで開いた結果

# base: '/' のビルドを /my-site/ に置いた
GET /my-site/ -> 200
"appChildren": 0, "bodyBg": "rgba(0, 0, 0, 0)", "text": ""
4xx: 404 /assets/index-BYSJLi2y.js, 404 /assets/index-C3YTNyfo.css, 404 /favicon.svg

# base: '/my-site/'
GET /my-site/ -> 200
"appChildren": 6, "bodyBg": "rgb(11, 92, 173)"
"abs": "/data.json → 失敗 404"
"rel": "/my-site/data.json → data.json を読めました"
4xx: 404 /data.json

5つのパターンの結果

./（相対パス）は、トップのページでは動きますが、下の階層の URL で同じ HTML を返すと壊れます。 4つ目と5つ目の違いは、次の SPA の節で使う 404.html の方法に関わります。React Router・Vue Router などの SPA を公開するなら、base は /リポジトリ名/ と絶対パスで書く方が安全です。

Astroのリンクも同じ

Astro でも base: '/my-site' を書くと、CSS（/my-site/_astro/Base.C0mivv07.css）には base が付きました。ページの中に自分で書いた <a href="/about/"> には付かず、クリックすると /about/ へ移動して 404 になりました。

---
const base = import.meta.env.BASE_URL   // この設定では "/my-site"
---
<a href="/about/">about</a>              <!-- /about/ に飛んで 404 -->
<a href={`${base}/about/`}>about</a>     <!-- /my-site/about/ で 200 -->

bad  -> /about/ 404
good -> /my-site/about/ 200 about

Vite の import.meta.env.BASE_URL は末尾に / が付いた /my-site/、Astro の import.meta.env.BASE_URL は設定に書いたとおりの /my-site でした。つなぐときに / が二重や抜けにならないように、どちらの形かを確かめてから書きます。Astro の公式ドキュメントも、base を設定したら自分で書く内部リンクに base を付けること、独自ドメインに移したら外すことを書いています。

SPA（React・Vue）で404になるときの対処（404.html）

この節では、React や Vue のアプリで、トップから移動すると動くのに、URL を直接開いたり再読み込みしたりすると 404 になる理由と直し方が分かります。

GitHub Pages は、URL のパスにあるファイルを返すだけで、Netlify の _redirects のような「どの URL でも index.html を返す」設定がありません。/my-site/users/42 というファイルは無いので 404 になります。

flowchart TD
    A[my-site/users/42 を<br>直接開く] --> B{users/42 の<br>ファイルがある}
    B --> C[無い]
    C --> D[404.html を返す<br>ステータス 404]
    D --> E[404.html が index.html の写しなら<br>アプリが起動して画面が出る]

公式ドキュメントは、公開するフォルダに 404.html（または front matter に permalink: /404.html を書いた 404.md）を置くと、それが 404 のページになると説明しています。これを使い、ビルドの後に index.html を 404.html にコピーすると、どの URL でもアプリが起動します。

npm run build
cp dist/index.html dist/404.html

Actions の workflow なら、npm run build の次の行に run: cp dist/index.html dist/404.html を足します。手元で /my-site/users/42 を開いた結果です。

GET /my-site/users/42 -> 404
"title": "pages-test", "appChildren": 6, "bodyBg": "rgb(11, 92, 173)"
"route": "path = /my-site/users/42"

画面は出て、アプリは location.pathname から /my-site/users/42 を読めました。ただし HTTP のステータスは 404 のままです。 検索エンジンは 404 のページを登録しないので、検索から来てほしいページがある SPA では、URL ごとに HTML を作る静的生成（Astro・Next.js の output: 'export' など）か、ほかのホスティングを選びます。

React Router などのルーターにも base を伝えます（React Router なら basename に import.meta.env.BASE_URL を渡す）。伝えないと、/my-site/users/42 を /users/42 として読めず、「ルートが無い」画面になります。

JekyllとNojekyll（_で始まるフォルダが消える）

この節では、ブランチから公開したときに一部のファイルだけが 404 になる原因と、.nojekyll の意味が分かります。

ブランチから公開すると、GitHub Pages はファイルを Jekyll に通してから配ります。 Jekyll は Markdown を HTML にしてくれる一方、公式ドキュメントによると、次のファイルは公開されません。

Astro の手元のビルドでは、CSS が _astro/Base.C0mivv07.css に出力されました。このフォルダごとブランチに置いて公開すると、_astro/ が除外されて CSS が 404 になります。公開するフォルダの一番上に、空の .nojekyll というファイルを置くと、Jekyll を通さずにそのまま配られます（GitHub の公式ブログ「Bypassing Jekyll on GitHub Pages」）。

touch dist/.nojekyll

GitHub Pages の Jekyll は 3.10.0、github-pages の gem は 232、Ruby は 3.3.4 です（pages.github.com の versions.json、2026年10月23日時点）。jekyll-relative-links・jekyll-readme-index・jekyll-titles-from-headings など9つのプラグインは、既定で有効で外せません。README.md だけのリポジトリでもページになるのは、jekyll-readme-index が README を入口として扱うためです。

Jekyll でプロジェクトサイトを作るときは、_config.yml の baseurl にリポジトリ名を書き、テンプレートの中ではパスに relative_url のフィルターを通します。

# _config.yml
title: My Site
baseurl: "/my-site"
url: "https://ユーザー名.github.io"

<link rel="stylesheet" href="{{ '/assets/css/style.css' | relative_url }}">

独自ドメインとHTTPSの設定

この節では、www.example.com のような自分のドメインで公開する手順と、DNS の値、HTTPS を有効にする方法が分かります。

公式ドキュメントは、DNS を設定する前に、先に GitHub の Settings → Pages で独自ドメインを登録するよう書いています。 逆の順にすると、その間にほかの人が同じドメインで Pages のサイトを作れてしまうためです。

DNSに設定する値

apex と www の両方を設定しておくと、GitHub Pages が片方からもう片方へ自動で転送します（どちら向きかは、Settings に登録したドメインで決まる）。公式ドキュメントは、*.example.com のようなワイルドカードのレコードは乗っ取りの危険があるので使わないよう強くすすめています。設定の確認は dig で行います（公式の例）。

dig www.example.com +nostats +nocomments +nocmd
dig example.com +noall +answer -t A

DNS のレコードの種類と dig の読み方は、関連記事「DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認」で扱っています。

CNAMEファイルの扱い（公開方法で違う）

Actions で公開するときは、独自ドメインは Settings（か API）だけで設定します。Astro の公式ドキュメントは public/CNAME を置く手順を案内していますが、GitHub の公式ドキュメントでは Actions の公開ではこのファイルは設定に使われない、と書かれています。独自ドメインに移したら、ビルドの base を / に戻します（configure-pages の base_path を使う workflow なら自動で空になります）。

HTTPSの注意

github.io のサイトは自動で HTTPS になります。独自ドメインでは Enforce HTTPS にチェックを入れると、HTTP で来た人も HTTPS に転送されます。証明書が出ないときは、公式ドキュメントでは次を確かめるよう書かれています。

• 余分な A・AAAA・ALIAS・ANAME・CNAME のレコードが残っていないか
• ドメイン名の全体が64文字未満か（証明書の名前の上限）
• Settings の Remove で一度外し、もう一度入力して Save すると、発行をやり直せる

ページの中に http:// の画像・CSS・JS が残っていると、混在コンテンツ（mixed content）としてブラウザに止められます。http:// を検索して https:// に直します。

GitHub Pagesの制限（容量・帯域・商用利用・非公開）

この節では、GitHub Pages で使える量の上限と、使ってはいけない用途が分かります。値は公式の「GitHub Pages limits」のページ（2026年10月23日時点）です。

公式ドキュメントは、GitHub Pages は「商用のサイト（オンラインビジネス・EC・主に商取引のためのサイト・商用の SaaS）」をホストするためのものではない、と書いています。会社の製品のドキュメントや OSS の紹介ページは広く使われていますが、商品の販売や有料のサービスを動かす用途には向きません。上限を超えると、GitHub のサポートから CDN を前に置くなどの提案が来たり、配信できなくなったりすることがあります。

非公開のリポジトリから公開しても、サイトそのものは誰でも見られます（Enterprise Cloud の private publishing を除く）。リポジトリを public から private に（または逆に）変えると、サイトの URL が変わる場合があると公式ドキュメントは書いています。

Netlify・Vercel・Cloudflare Pagesとの違い

この節では、同じように静的サイトを公開できるサービスとの事実の違いと、選び方が分かります。各社の公式の料金・制限のページの記載です（2026年10月23日時点）。

ビルドコマンドと公開するフォルダ（dist・public）の考え方は、どのサービスでも同じです。Netlify の使い方とデプロイの方法は、関連記事「Netlifyとは｜使い方・料金・デプロイ方法とエラー対処を実例で」で扱っています。

よくあるエラーと直し方（404・反映されない・Actions）

この節では、症状やエラー文から原因と直し方を引けます。

症状の早見表

公式の 404 のトラブルシューティングのページは、ほかに「公開に使うブランチが既定のブランチでない」「admin 権限を持つ人のコミットが無い」「リポジトリの公開範囲を変えた」「private のリポジトリでプランが切れた」も 404 の原因に挙げています。

Actionsのエラー文（deploy-pages・configure-pages）

actions/deploy-pages v5.0.1 と actions/configure-pages v6.0.0 のソースにあるエラー文と、出る条件です。

Get Pages site failed. Please verify that the repository has Pages enabled and configured to build using GitHub Actions は、configure-pages が Pages の設定を読めなかったときの文です。Settings → Pages の Source が「Deploy from a branch」のまま Actions の workflow を動かしたときにも、この方向を確かめます。

公開先の環境 github-pages には、公開できるブランチを決める保護のルールを付けられます。公式ドキュメントは、既定のブランチだけが公開できるようにするルールをすすめています。ほかのブランチから workflow を動かしたときに公開で止まったら、Settings → Environments → github-pages のルールを確かめます。

• 1Settings → Pages の Source は合っているかブランチ公開なら Deploy from a branch、workflow なら GitHub Actions
• 2公開する場所の一番上に index.html があるかActions なら成果物（dist・public）の一番上
• 3ビルドの base はリポジトリ名と合っているか独自ドメインなら / に戻す
• 4_ で始まるフォルダがあるならJekyllを外したかブランチ公開なら .nojekyll
• 5Actions のタブで最後の実行が緑か失敗したジョブのログの最後の行を読む
• 6DevTools の Network で 404 のファイルのパスを見たか/リポジトリ名/ が抜けていないか

よくある質問

Q. GitHub Pagesとは簡単に言うと何ですか？ A. GitHub のリポジトリにある HTML・CSS・JavaScript を、ユーザー名.github.io の URL で公開できる、GitHub の静的サイトのホスティングです。PHP やデータベースなどサーバーでの処理は動きません。

Q. GitHub Pagesは無料ですか？料金はかかりますか？ A. 公開リポジトリなら GitHub Free で無料です。非公開のリポジトリから公開するには Pro・Team などの有料プランが要ります（2026年10月23日時点）。

Q. 非公開（private）のリポジトリで使えますか？サイトも非公開にできますか？ A. Pro・Team 以上なら非公開のリポジトリから公開できますが、サイトは誰でも見られます。見られる人を限定できるのは、組織が GitHub Enterprise Cloud を使っている場合だけです。

Q. 商用利用はできますか？ A. 公式ドキュメントは、オンラインビジネス・EC・商用の SaaS のサイトには使わないよう書いています。製品のドキュメントや OSS の紹介などに使われています。

Q. 容量や転送量の制限は？ A. 公開するサイトは 1GB まで、転送量は月 100GB（ソフトな上限）、公開の処理は10分まで、ブランチ公開のビルドは1時間に10回（ソフトな上限）です（2026年10月23日時点）。

Q. HTMLファイルを公開するだけなら、何をすればよいですか？ A. リポジトリの一番上に index.html を置いて push し、Settings → Pages で Source を Deploy from a branch、ブランチを main、フォルダを / (root) にして Save します。最短手順の節にコマンドがあります。

Q. CSSが反映されない・画面が真っ白になります。 A. プロジェクトサイトで、ビルドの base が / のままのことが多いです。手元の実測では、JS と CSS が /assets/… を探して 404 になり、画面が真っ白でした。base を /リポジトリ名/ にします。

Q. 更新したのに反映されません。 A. 公式ドキュメントは、push から公開まで最大10分かかることがあると書いています。Actions のタブで実行が終わったかを確かめ、ブラウザは強制再読み込みします。ブランチ公開では、admin 権限のある人のコミットが要る場合があります。

Q. ReactやVueのアプリを公開できますか？ A. できます。ビルドの base をリポジトリ名に合わせ、ルーターにも base を渡します。URL を直接開くと 404 になる問題は、index.html を 404.html にコピーする方法か、hash のルーターで避けます。

Q. .nojekyllとは何ですか？ A. 公開するフォルダの一番上に置く空のファイルで、ブランチ公開のときに Jekyll を通さないようにします。Jekyll は _ で始まるフォルダ（Astro の _astro/ など）を公開しないので、ビルド済みのファイルをブランチに置くときに使います。

Q. 独自ドメインは使えますか？HTTPSになりますか？ A. 使えます。Settings → Pages で先にドメインを登録してから、www は CNAME、apex は A（185.199.108.153 など4つ）と AAAA を DNS に作ります。証明書は Let's Encrypt で自動で発行され、Enforce HTTPS で HTTPS に統一できます。

Q. 公開をやめるには？ A. 公式ドキュメントでは、「Your site is live at」の表示の横にある「…」のメニューから「Unpublish site」を選びます。今の公開が取り消され、リポジトリの中身や設定は残ります。

Q. GitHub PagesとNetlifyはどちらがよいですか？ A. リポジトリと同じ場所で完結させたいドキュメントやポートフォリオなら GitHub Pages、SPA の書き換え・フォーム・サーバーの処理が要るなら Netlify が選ばれやすいです。違いの節の表のとおりです。

まとめ

• GitHub Pages は、リポジトリの静的なファイルを github.io で無料公開する機能。公開リポジトリなら Free で使え、サーバーの処理は動かない。
• 公開方法は、ブランチの /・ブランチの /docs・GitHub Actions の3通り。ビルドが要るサイトは Actions が公式のおすすめ。
• プロジェクトサイトの URL は /リポジトリ名/ の下。base が / のままだと、JS・CSS が 404 になり画面が真っ白になった。
• JS の中の '/data.json' の文字列は base が付かない。import.meta.env.BASE_URL を付ける。Astro の自分で書いたリンクも同じ。
• SPA は index.html を 404.html にコピーすると直打ちでも動く（ステータスは 404）。base が ./ だと下の階層で壊れた。
• ブランチ公開では Jekyll が _ 始まりのフォルダを除外する。ビルド済みのファイルを置くなら .nojekyll。Actions の成果物では . 始まりのファイルが既定で除外される。
• 独自ドメインは Settings で登録してから DNS。www は CNAME、apex は A・AAAA。Actions の公開では CNAME ファイルは使われない。
• 上限はサイト 1GB・転送 月100GB・公開10分。EC・SaaS などの商用サイトには使わない。

参考・出典

確認日はいずれも 2026年10月23日です。

• GitHub Docs「What is GitHub Pages?」：https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages
• GitHub Docs「Configuring a publishing source for your GitHub Pages site」：https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site
• GitHub Docs「Using custom workflows with GitHub Pages」：https://docs.github.com/en/pages/getting-started-with-github-pages/using-custom-workflows-with-github-pages
• GitHub Docs「GitHub Pages limits」：https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits
• GitHub Docs「Troubleshooting 404 errors for GitHub Pages sites」：https://docs.github.com/en/pages/getting-started-with-github-pages/troubleshooting-404-errors-for-github-pages-sites
• GitHub Docs「Creating a custom 404 page for your GitHub Pages site」：https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-custom-404-page-for-your-github-pages-site
• GitHub Docs「Unpublishing a GitHub Pages site」：https://docs.github.com/en/pages/getting-started-with-github-pages/unpublishing-a-github-pages-site
• GitHub Docs「Changing the visibility of your GitHub Pages site」：https://docs.github.com/en/enterprise-cloud@latest/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site
• GitHub Docs「About GitHub Pages and Jekyll」：https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/about-github-pages-and-jekyll
• GitHub Docs「Managing a custom domain for your GitHub Pages site」：https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site
• GitHub Docs「Verifying your custom domain for GitHub Pages」：https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/verifying-your-custom-domain-for-github-pages
• GitHub Docs「Securing your GitHub Pages site with HTTPS」：https://docs.github.com/en/pages/getting-started-with-github-pages/securing-your-github-pages-site-with-https
• GitHub Docs「GitHub's plans」：https://docs.github.com/en/get-started/learning-about-github/githubs-plans
• GitHub「Pricing」：https://github.com/pricing
• GitHub Pages「Dependency versions」：https://pages.github.com/versions.json
• GitHub Blog「Bypassing Jekyll on GitHub Pages」：https://github.blog/news-insights/the-library/bypassing-jekyll-on-github-pages/
• GitHub「actions/upload-pages-artifact」：https://github.com/actions/upload-pages-artifact
• GitHub「actions/deploy-pages」：https://github.com/actions/deploy-pages
• GitHub「actions/configure-pages」：https://github.com/actions/configure-pages
• Vite「Deploying a Static Site」：https://vite.dev/guide/static-deploy
• Astro Docs「Deploy your Astro Site to GitHub Pages」：https://docs.astro.build/en/guides/deploy/github/
• GitHub「withastro/action」：https://github.com/withastro/action
• Hugo「Deploy to GitHub Pages」：https://gohugo.io/host-and-deploy/deploy-to-github-pages/
• Netlify「Pricing」：https://www.netlify.com/pricing/
• Vercel「Hobby Plan」：https://vercel.com/docs/plans/hobby
• Cloudflare Pages「Limits」：https://developers.cloudflare.com/pages/platform/limits/
• Cloudflare Pages「Functions - Pricing」：https://developers.cloudflare.com/pages/functions/pricing/
• MDN「GitHub Pages の使い方」：https://developer.mozilla.org/ja/docs/Learn_web_development/Howto/Tools_and_setup/Using_GitHub_pages

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。