GitHub Pages は、リポジトリに置いた HTML・CSS・JavaScript をそのまま Web サイトとして公開できる GitHub の機能です。公開方法は「ブランチの中身をそのまま公開する」か「GitHub Actions でビルドした成果物を公開する」かの2通りで、静的サイトジェネレーターや Vite などのビルドが必要なら後者を選びます。この記事では、2つの公開方法の手順、独自ドメインと HTTPS の設定、よくある「表示されない」「CSS が読み込まれない」の原因、そして WordPress のサイトを静的に書き出して載せる場合の注意点までを説明します。
公開する前に知っておくこと
GitHub Pages は 静的ファイルを配信するだけ のサービスです。PHP やデータベースは動かないため、WordPress そのものを置くことはできません。お問い合わせフォームのようにサーバー側の処理が要る機能は、外部のフォームサービスなどに任せる必要があります。
公開される URL は、リポジトリの種類で決まります。
- ユーザー（組織）サイト: リポジトリ名を
ユーザー名.github.ioにすると、https://ユーザー名.github.io/で公開されます。1アカウントに1つです。 - プロジェクトサイト: それ以外のリポジトリは
https://ユーザー名.github.io/リポジトリ名/で公開されます。URL の途中にリポジトリ名が入る点が、あとで出てくる「CSS が読み込まれない」問題の原因になります。
公開リポジトリなら無料のプランで使えますが、非公開リポジトリから公開するには有料プランが必要です。また、公開したサイトは、リポジトリを非公開にしていてもインターネット上のだれでも閲覧できます。サイトの容量や帯域、ビルドの回数には目安となる上限があり、ネットショップや SaaS のような商用サービスの配信先として使うことは利用規約で想定されていません。条件は改定されることがあるので、使い始める前に公式ドキュメントの「使用制限」と利用規約を確かめてください（2026年10月現在）。
方法1: ブランチの中身をそのまま公開する
手書きの HTML や、ビルド済みのファイルを置くだけのサイトならこの方法が手軽です。
- リポジトリのルートか
docs/フォルダにindex.htmlを置いて push します。 - リポジトリの「Settings」から「Pages」を開きます。
- 公開元（Source）として「Deploy from a branch」を選び、ブランチ（例:
main）とフォルダ（/ (root)か/docs）を指定して保存します。 - 数十秒から数分で公開されます。進み具合はリポジトリの「Actions」タブに表示される pages のワークフローで確認できます。
画面の項目名は変わることがあるので、表記が違う場合は「何を設定する項目か」で読み替えてください。
この方法では、GitHub が裏側で Jekyll（静的サイトジェネレーター）を通してからファイルを公開します。そのため、_ で始まるフォルダ（例: _next、_assets）が公開されずに 404 になることがあります。Jekyll を使わないサイトでは、公開するフォルダの直下に中身が空の .nojekyll というファイルを置くと、この処理が行われなくなります。
方法2: GitHub Actions でビルドして公開する
Vite・Astro・Hugo・Next.js の静的書き出しなど、ビルドが必要なサイトはこちらが基本です。ビルドの成果物をリポジトリにコミットせずに済むので、ソースと成果物が混ざりません。
まず「Settings」→「Pages」で公開元を「GitHub Actions」に切り替えます。次に .github/workflows/pages.yml を作ります。次の例は Node.js でビルドし、dist フォルダを公開するものです。
name: Deploy to GitHub Pages
on:
push:
branches: [main]
workflow_dispatch:
# Pages への公開に必要な権限だけを与える
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@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run build
- uses: actions/configure-pages@v5
- uses: actions/upload-pages-artifact@v3
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@v4ポイントは3つです。
- 権限:
pages: writeとid-token: writeがないと公開の段階で失敗します。リポジトリ全体の書き込み権限は不要です。 - 成果物のフォルダ:
pathには、ビルド後にindex.htmlが置かれるフォルダを指定します。Vite ならdist、Hugo ならpublicが一般的です。 - アクションのバージョン: 例の
@v4や@v5は執筆時点のものです。各アクションのリポジトリで最新のメジャーバージョンと変更点を確かめてから使ってください。
失敗したときは「Actions」タブで該当の実行を開き、赤くなっているステップのログを最後から読みます。npm ci で止まっていればロックファイルの不一致、deploy で止まっていれば公開元の設定が「GitHub Actions」になっていないか権限の不足、というように、どのステップで止まったかで原因を絞れます。
「CSS が読み込まれない」「ページが 404 になる」とき
公開はできたのに表示が崩れる場合、多くはプロジェクトサイトの URL にリポジトリ名が入ることが原因です。
- ルートからのパスで書いている: HTML に
/assets/style.cssと書くと、ブラウザーはhttps://ユーザー名.github.io/assets/style.cssを探しに行き、リポジトリ名の部分が抜けて 404 になります。相対パスにするか、ビルドツールの設定でベースのパスを指定します。Vite ならvite.config.jsのbaseに'/リポジトリ名/'を指定します。 - 大文字と小文字の違い: 手元の Windows や macOS では区別されなくても、公開先では
Logo.pngとlogo.pngは別のファイルです。 - SPA の直接アクセス: React などで作った SPA は、
/aboutを直接開くと 404 になります。GitHub Pages にはリライトの設定がないため、ハッシュ形式のルーティングにするか、404.htmlでindex.htmlと同じ内容を返す工夫が必要です。後者はステータスコードが 404 のままになるので、検索エンジンに載せたいページには向きません。
独自の 404 ページを出したいときは、公開するフォルダの直下に 404.html を置きます。
独自ドメインを設定する
- 「Settings」→「Pages」の「Custom domain」に
www.example.comのように入力して保存します。 - DNS を設定します。
wwwのようなサブドメインは、CNAME レコードでユーザー名.github.ioに向けます。example.comのようなルートドメインは、GitHub の公式ドキュメントに掲載されている A レコード（IPv6 なら AAAA レコード）を設定します。IP アドレスは他サイトの解説から写さず、公式ドキュメントの最新の値を使ってください。 - DNS が反映されると証明書が発行され、「Enforce HTTPS」を有効にできるようになります。証明書の発行には時間がかかることがあり、DNS の設定が誤っていると有効にできません。
注意したい点がいくつかあります。
- ドメインの検証: アカウントや組織の設定からドメインを検証しておくと、自分が使わなくなったサブドメインを第三者のリポジトリに乗っ取られる危険を減らせます。独自ドメインを使うなら先に済ませておくと安心です。
- ワイルドカードの DNS レコードは使わない:
*.example.comを GitHub に向けると、乗っ取りの原因になります。 - CNAME ファイル: 方法1では、設定画面で入力すると公開するフォルダに
CNAMEファイルが作られます。方法2（GitHub Actions）では、このファイルは使われず、設定画面の値が使われます。 - メールのレコードを消さない: DNS を編集するときは、MX レコードや SPF の TXT レコードなど既存のレコードを残したまま追加します。
WordPress のサイトを静的に書き出して載せる場合
更新の少ないコーポレートサイトなどは、WordPress で作ったページを静的な HTML に書き出して GitHub Pages に載せる方法があります。書き出しには「Simply Static」などのプラグインを使います。
- WordPress 本体は、ローカル環境や、アクセスを制限したサーバーに置いたまま運用します。公開側には HTML だけが出るので、ログイン画面が攻撃される心配はなくなります。
- 書き出し先の URL（
https://ユーザー名.github.io/リポジトリ名/か独自ドメイン）を書き出しの設定で正しく指定しないと、リンクや画像の URL が元の WordPress のアドレスのまま残ります。 - コメント・検索・フォームなど、サーバー側で動く機能は使えなくなります。代わりの手段を決めてから移行します。
- 書き出した HTML をリポジトリに push する作業を GitHub Actions やスクリプトで自動にしておくと、更新のたびの手間が減ります。
元の WordPress の環境は、移行後もバックアップを取って残しておいてください。書き出し結果に問題があったときに作り直せます。
まとめ
- GitHub Pages は静的ファイルの配信だけ。PHP や WordPress 本体は動かない。
- ビルドが不要ならブランチ公開、ビルドが必要なら GitHub Actions で公開する。Jekyll を使わないブランチ公開には
.nojekyllを置く。 - プロジェクトサイトは URL にリポジトリ名が入る。CSS や画像の 404 は、ベースのパスの設定でまず確かめる。
- 独自ドメインは公式ドキュメントの値で DNS を設定し、ドメインの検証と HTTPS の強制を有効にする。
- WordPress を載せるなら静的に書き出し、書き出し先の URL とサーバー側の機能の代わりを先に決める。