GitHub Pagesとは？料金・無料の範囲と容量制限、公開手順・商用利用・SEO設定【2026年】

GitHub Pagesは、GitHubのリポジトリに置いたHTML・CSS・JavaScriptを、そのままWebサイトとして公開できるGitHubの機能です。パブリックリポジトリなら無料で使えます。ただし「プライベートリポジトリにすればサイトも非公開になる」は誤りで、GitHub ProやTeamで隠せるのはソースコードだけです。この記事では、無料で使える範囲と有料プランが要るケース、容量・帯域の制限、商用利用の可否、ブラウザだけで公開する手順、ブランチ公開とGitHub Actionsの選び方、検索結果に載せるためのSEO設定までを、2026年10月23日時点の公式ドキュメントと応答ヘッダーの計測結果をもとに整理します。

まとめ：GitHub Pagesの要点

• GitHub Pagesは静的サイト専用のホスティングです。PHPやデータベースなど、サーバー側で動く処理は実行できません。
• GitHub Freeではパブリックリポジトリからのみ公開できます。GitHub Pro・Team・Enterprise Cloud・Enterprise Serverならプライベートリポジトリからも公開できますが、通常は公開されたサイト自体は誰でも見られます。
• 閲覧者を限定する「プライベート公開」は、組織がGitHub Enterprise Cloudを使っている場合だけの機能です。Enterprise Serverでは管理者の設定で公開範囲が変わります。
• 公開サイトの上限は1GBで、帯域の月100GBとビルドの1時間10回はソフトリミットです。デプロイは10分でタイムアウトします。
• ECサイトや商用SaaSを無料で運営する用途は、公式に禁止されています。
• 初めてなら、<ユーザー名>.github.ioという名前のリポジトリを作り、Settings → Pagesでブランチを選ぶだけで公開できます。反映には最大10分かかります。
• ビルド工程を細かく制御しないならブランチ公開、Jekyll以外のジェネレーターを使うならGitHub Actionsでの公開が向いています。
• サイトマップとSearch Consoleは検索掲載の必須条件ではありませんが、URLの発見と検索状況の確認に役立ちます。既定URLのプロジェクトサイトでは、ホスト直下のrobots.txtを自分のリポジトリだけでは管理できません。

GitHub Pagesとは：リポジトリから静的サイトを配信する仕組み

公式ドキュメントは、GitHub Pagesを「GitHubのリポジトリからHTML・CSS・JavaScriptファイルを取り出し、必要に応じてビルド処理を通してWebサイトとして公開する静的サイトホスティングサービス」と説明しています。サーバーの契約やOSの管理は不要で、リポジトリにプッシュした内容がそのままサイトに反映されます。

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

サイトの種類は、アカウントに紐づくユーザー・組織サイトと、リポジトリに紐づくプロジェクトサイトの2種類です。

個人のポートフォリオや技術ブログならユーザーサイト、ライブラリのドキュメントや製品紹介ならプロジェクトサイトが向いています。URLの確認場所や、URLが変わる条件、404になったときの切り分けはGitHub PagesのURLの確認方法と404の切り分けで扱っています。

応答ヘッダーで見る配信とキャッシュ

2026年10月23日に、GitHub Pagesで公開されているpages.github.comとjekyll.github.io/minima/へcurl -sI <URL>でアクセスし、応答ヘッダーを確認しました。

どの応答にもvia: 1.1 varnishとx-served-by: cache-nrt-…が付いており、成田（NRT）の名前を持つキャッシュサーバーから返っていました。max-age=600は、応答の鮮度を600秒として扱う指定で、その間はキャッシュがオリジンに問い合わせずに保存済みの応答を返せます。トップページのage: 483は、オリジンサーバーでその応答が生成または正常に検証されてから、推定483秒（約8分）が経過していることを示しています。この場合、追加の経過時間を無視した鮮度の残りは117秒で、受信後さらに600秒間有効になるわけではありません。プッシュしたのに表示が変わらないときは、公式の「反映まで最大10分」という目安に加えて、このキャッシュも疑ってください。

料金：無料で使える範囲と有料プランが要るケース

GitHub Pages自体に追加料金はありません。料金が関係するのは、どのプランのリポジトリから公開するかと、閲覧者を限定したいかどうかの2点です。

誤解が多いのは、プライベートリポジトリから公開したサイトの扱いです。公式ドキュメントは「リポジトリがプライベートでも、GitHub Pagesのサイトはインターネット上に公開される」と警告しています。GitHub ProやTeamで隠せるのはソースコードで、公開されたページは誰でも閲覧できます。サイトの閲覧範囲まで制限できるのは、Enterprise Cloudのプライベート公開と、Enterprise Serverの管理者設定（プライベートモードで公開サイトを許可しない構成）です。社外秘の資料を置く前に、この点を必ず確認してください。Enterprise Cloudでの公開範囲の切り替えはGitHub Pagesサイトの可視性の変更に手順があります。

閲覧者を限定するプライベート公開の条件

閲覧をリポジトリの読み取り権限を持つ人に限る「プライベート公開」は、組織がGitHub Enterprise Cloudを使っている場合に限り利用できます。対象は、組織が所有するプライベートまたは内部リポジトリから公開するプロジェクトサイトで、組織サイトにはアクセス制御をかけられません。プライベート公開されたサイトは、通常の公開とは別の*.pages.github.io配下の固有サブドメインで配信されます。Enterprise Managed Usersを使う企業では、サイトはすべてプライベート公開になります。

GitHub Pagesには、Basic認証やパスワードをかける設定はありません。「社内だけに見せたい」「特定の取引先だけに見せたい」という要件は、Enterprise Cloudのプライベート公開を使うか、アクセス制御ができる別のホスティングを選ぶことになります。

有料プランの価格とActionsの課金

GitHubの料金ページの表示（2026年10月23日時点）では、Teamが1ユーザーあたり月4ドル、Enterpriseが1ユーザーあたり月21ドルからです。どちらにも「最初の12か月」の注記が付いているため、契約前に料金ページで最新の条件を確認してください。

GitHub Actionsで公開する場合の実行時間について、GitHub Actionsの課金文書は、標準のGitHubホステッドランナーはパブリックリポジトリとGitHub Pages向けの利用では無料と書いています。大型ランナーは有料です。単価と無料枠はGitHub Actionsの料金と無料枠で整理しています。

容量・帯域・ビルドの制限

公式のGitHub Pagesの制限ページには、次の上限が載っています。

「ソフトリミット」と明記されているのは帯域とビルド回数だけで、公開サイトの1GBには付いていません。ビルド回数の上限は、独自のGitHub Actionsワークフローでビルド・公開する場合には適用されません。上限を大きく超えると、GitHub SupportからCDNの前置きや別のホスティングへの移行などを提案するメールが届くか、サイトが配信されなくなることがあります。リクエストが集中してレート制限にかかった場合は、HTTPステータス429が返ります。

動画や大量の画像を置くと1GBに届きやすくなります。大きなファイルは外部のストレージやCDNに置き、GitHub PagesにはHTMLと軽いアセットだけを載せる構成にすると、容量と帯域の消費を抑えられます。

できないこと・商用利用の可否

GitHub Pagesは静的ファイルを返すだけなので、サーバー側でプログラムを動かすことはできません。PHP、データベース、サーバー側で処理する問い合わせフォーム、ログイン機能は、そのままでは実現できません。フォームを置きたい場合は、送信先を外部のフォームサービスやAPIにします。

商用利用で禁止されている用途

公式の制限ページは、GitHub Pagesを「オンラインビジネス、ECサイト、または主に商取引の促進や商用SaaSの提供を目的とするサイトを運営するための無料ホスティングサービス」として使うことは想定されておらず、許可もされていないと明記しています。パスワードやクレジットカード番号を送信するような機密性の高い取引にも使わないよう求めています。

一方で、企業のプロジェクトのドキュメント、製品の紹介ページ、エンジニアのポートフォリオのように、商取引そのものを担わないサイトは広く使われています。判断基準は、決済や会員管理の有無ではなく、サイトの主目的が商取引の促進や商用SaaSの提供に当たるかどうかです。決済やサーバー処理が必要なら、Vercel、Cloudflare Pages、Firebase Hostingのように、サーバー側の処理を組み合わせられるサービスを検討します。VercelとCloudflare Pagesの料金の増え方と商用条件の違いはVercelとCloudflare Pagesの比較で扱っています。

ブラウザだけで公開する初回の手順

Gitをインストールしていなくても、GitHubの画面操作だけで公開できます。ここでは公式のGitHub Pagesのクイックスタートに沿って、ユーザーサイト（<ユーザー名>.github.io）を作る流れを示します。GitHubの画面は英語表記なので、ボタン名は英語のまま書きます。

リポジトリ作成とindex.htmlの配置

1. 画面右上の「+」からNew repositoryを選びます。
2. リポジトリ名に<ユーザー名>.github.ioを入力します。ユーザー名がoctocatならoctocat.github.ioです。
3. 公開範囲を選びます。GitHub Freeならパブリックを選びます（プライベートでは公開できません）。
4. Add READMEをオンにしてCreate repositoryを押します。
5. Add file → Create new fileでindex.htmlを作り、次の内容を貼ってCommit changesを押します。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>はじめてのGitHub Pages</title>
</head>
<body>
  <h1>公開できました</h1>
</body>
</html>

GitHub Pagesは、公開元のフォルダの最上位にあるindex.html、index.md、README.mdのいずれかを入口のファイルとして探します。index.htmlを置かずに、クイックスタートのようにREADMEだけで公開すると、READMEに書いた内容がトップページになります。プロジェクトサイトにする場合は、リポジトリ名を任意にし、公開URLは<ユーザー名>.github.io/<リポジトリ名>/になります。

Settings → Pagesでの公開ソース選択

1. リポジトリのSettingsタブを開き、左メニューの「Code, planning, and automation」にあるPagesを選びます。
2. 「Build and deployment」のSourceでDeploy from a branchを選びます。
3. Branchでmainとフォルダ/ (root)を選び、Saveを押します。
4. 数分待って同じ画面を開き直すと、上部に「Your site is live at」と公開URLが表示され、Visit siteから開けます。

公式ドキュメントは、プッシュから反映まで最大10分かかるとしています。ブランチ公開でも、裏ではGitHub Actionsのワークフローが動いてデプロイされるため、進み具合と失敗はリポジトリのActionsタブで確認できます。1時間たっても表示されない場合は、ビルドエラーの有無をActionsタブで見て、URLやファイル名の誤りはGitHub Pagesが表示されないときの切り分けを参照してください。

公開後の更新と非公開化

更新は、公開元のブランチにファイルをコミットするだけです。ブランチ公開なら、変更が公開元のブランチに入るたびに自動で再デプロイされます。画面から編集してもよく、手元で編集してGitコマンドでプッシュしてもかまいません。

サイトを止めたいときは、公開URLの表示（「Your site is live at」）の横にある「…」メニューからUnpublish siteを選びます。公式ドキュメントによると、この操作は現在のデプロイを取り除くだけで、リポジトリの設定や内容は残ります。ブランチ公開なら公開ソースを設定し直してコミットすれば、Actions公開ならワークフローを再実行すれば、再び公開されます。リポジトリをプライベートにする操作は、GitHub Freeでは公開を止める手段になりますが、有料プランではサイトが公開されたまま残る点に注意してください。

公開方式の選び方：ブランチ公開とGitHub Actions

公開ソースには「ブランチから公開（Deploy from a branch）」と「GitHub Actionsで公開」の2つがあります。前章の手順はブランチ公開です。

公開方式に関する公式の推奨と選択基準

公開ソースの設定ページは「ビルド工程を制御する必要がなければ、特定のブランチへのプッシュで公開することを推奨する」と書いています。一方、Jekyllの解説ページには「GitHub Actionsがデプロイと自動化の推奨手段になった」という注記があります。両者は矛盾しているように見えますが、公開ソースの設定ページの基準は「HTMLかJekyllか」ではなく「ビルド工程を制御する必要があるか」です。Jekyllでも、GitHub Pages標準の版とプラグインで足りるならブランチ公開で問題なく、版やプラグインを自由に選びたいならActionsが向いています。

ブランチ公開では、公開するブランチと、ルート（/）か/docsフォルダのどちらかを選びます。ブランチ公開のJekyllビルドが使うのはgithub-pages gemのv232（2024年8月リリース）で、Jekyll本体は3.10.0です。Jekyllの最新は4.4.1（2025年1月リリース）なので、4系の機能や許可リストにないプラグインを使いたい場合は、Actionsで自分のビルドを組みます。逆に、Jekyllを使わない手書きのHTMLをブランチ公開するときは、公開元のルートに空の.nojekyllファイルを置くとJekyllのビルドを止められます。MkDocsでGitHub Pagesに公開する手順のように、Jekyll以外のジェネレーターにはActions公開が推奨されますが、手元で生成した静的ファイルをブランチから公開することもできます。

GitHub.com向けの静的ファイル公開ワークフロー

GitHubが用意している静的サイト用のテンプレート（starter-workflowsのpages/static.yml）は、2026年10月23日時点でactions/checkout@v4とactions/upload-pages-artifact@v3など古い版を参照しています。各アクションの最新リリースはcheckout v7.0.1、configure-pages v6.0.0、upload-pages-artifact v5.0.0、deploy-pages v5.0.1で、メジャー版を置き換えると次のようになります。.github/workflows/pages.ymlとして保存し、Settings → Pagesの公開ソースを「GitHub Actions」にします。

name: Deploy static content to Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

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

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

jobs:
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/configure-pages@v6
      - uses: actions/upload-pages-artifact@v5
        with:
          path: './public'
      - id: deployment
        uses: actions/deploy-pages@v5

pathには公開するHTMLのフォルダを指定します。この例にはビルド処理がないため、mainブランチにpublicフォルダとindex.htmlを用意するか、アップロード前に生成処理を追加します。手書きのHTMLをリポジトリ直下に置いているなら'.'です。版を上げるときに注意したいのが、upload-pages-artifactのv4で入った変更です。v4以降はドットで始まるファイルとフォルダがアーティファクトから除外されるため、.well-known/配下のファイルなどが公開されなくなります。v5で追加されたinclude-hidden-files: trueを指定すれば含められます（.gitと.githubは常に除外）。ワークフローの基本はGitHub Actionsの解説を、社内のデプロイ工程ごと整えたい場合はDevOps・CI/CD導入支援を参照してください。

独自ドメインとHTTPS

github.ioのサイトは、2016年6月15日以降に作成されたものならHTTPSで自動配信されます。独自ドメインを設定した場合も、GitHubがLet’s Encryptから証明書を自動取得し、Settings → Pagesの「Enforce HTTPS」で常時HTTPSにできます。この項目は、ドメインを追加してから選べるようになるまで最大24時間かかります。また、証明書を発行するにはドメイン名全体が64文字未満である必要があります。

独自ドメインでは、先にアカウントや組織でドメインの所有権を確認（verify）しておくことが推奨されています。確認しておかないと、リポジトリを削除したりプランをダウングレードしたりしたときに、他のユーザーにそのドメインでサイトを公開される「ドメイン乗っ取り」が起こりえます。Aレコード・CNAMEの具体的な値と、wwwと素のドメインの組み合わせ方はGitHub PagesのURLとカスタムドメインの解説にまとめています。

GitHub PagesのSEO設定と検索状況の確認

GitHub Pagesで公開したサイトは、公開しただけでは検索結果に出るまで時間がかかります。自分でできる対策は、サイトマップを用意する、ページごとのタイトルと説明文を整える、Search Consoleで所有権を確認してサイトマップを送信する、の3つです。

Jekyllプラグインによるサイトマップとメタタグの出力

ブランチ公開のJekyllでも、jekyll-sitemap（1.4.0）とjekyll-seo-tag（2.8.0）はGitHub Pagesの対応プラグイン一覧に入っているため、そのまま使えます。_config.ymlに次のように追加します。

url: "https://example.github.io"
plugins:
  - jekyll-sitemap
  - jekyll-seo-tag

jekyll-sitemapはビルド時にsitemap.xmlを生成し、jekyll-seo-tagはレイアウトの<head>内に書いた{% seo %}の位置に、titleタグ、meta description、canonical、OGPを出力します。GitHub Pages標準のJekyll環境では、未設定のurlとbaseurlをGitHub Metadataが補完します。独自のビルド環境では公開先に合わせて設定し、生成されたサイトマップとcanonicalの絶対URLを確認してください。HugoやAstroなど他のジェネレーターにも同等の機能があるので、それぞれの設定でサイトマップ出力を有効にします。

プロジェクトサイトのrobots.txtの配置条件

robots.txtは、ホストのルート（/robots.txt）に置いたものだけが読まれます。プロジェクトサイトは<owner>.github.io/<リポジトリ名>/という下の階層で公開されるため、リポジトリにrobots.txtを置いても検索エンジンには読まれません。ルートのrobots.txtを管理しているのは、同じアカウントのユーザーサイト（<owner>.github.ioリポジトリ）です。プロジェクトサイトでrobots.txtを細かく制御したい場合は、ユーザーサイト側に置くか、独自ドメインを割り当てます。

ユーザーサイトや独自ドメインのサイトなら、ルートにrobots.txtを置いてサイトマップの場所を伝えられます。

User-agent: *
Allow: /
Sitemap: https://example.github.io/sitemap.xml

github.ioサイトのSearch Console登録方式

github.ioのDNSは利用者が編集できないため、github.ioのサイトでは、DNSレコードで所有権を確認するSearch Consoleのドメインプロパティは使えません。URLプレフィックスのプロパティを作り、HTMLファイルかmetaタグを置いて確認します。確認手順とアクセス解析タグの設置はGitHub Pagesの記事のアクセス解析の章で扱っています。独自ドメインを使えばドメインプロパティで登録でき、サイトを別のホスティングへ移しても検索の評価をURLごと引き継ぎやすくなります。

よくある質問

GitHub Pagesは無料で使えますか？

パブリックリポジトリから公開するなら、GitHub Freeで無料です。プライベートリポジトリから公開するにはGitHub Pro・Team・Enterprise Cloud・Enterprise Serverのいずれかが必要です。通常の公開サイトは誰でも閲覧できますが、Enterprise Cloudのプライベート公開やEnterprise Serverの管理設定による例外があります。

GitHub Pagesのサイトにパスワードをかけられますか？

Basic認証やパスワードの設定はありません。閲覧者を限定できるのは、組織がGitHub Enterprise Cloudを使っている場合のプライベート公開で、対象は組織のプロジェクトサイトです。Enterprise Serverでは、管理者の設定で公開範囲が変わります。

GitHub Pagesは商用利用できますか？

オンラインビジネス、ECサイト、商用SaaSなど、商取引の促進や商用SaaSの提供を主な目的とするサイトを無料で運営する用途は、公式に禁止されています。企業のドキュメントや製品紹介ページでも、主目的がそれに当たる場合は禁止用途に該当します。

GitHub Pagesの容量はどれくらいですか？

公開サイトは1GBまでで、帯域は月100GB、ビルドは1時間10回がソフトリミットです。ただし、独自のGitHub Actionsワークフローでビルド・公開する場合、ビルド回数の制限は適用されません。デプロイは10分を超えるとタイムアウトします。

更新したのにサイトが変わらないのはなぜですか？

公式には反映まで最大10分かかるとされています。加えて、応答にcache-control: max-age=600が付く場合は、ブラウザや中間キャッシュが最大10分間は古い内容を返すことがあります。1時間たっても変わらない場合は、Actionsタブでビルドやデプロイが失敗していないかを確認します。

関連記事

• GitHub PagesのURLはどこで確認する？表示されない原因・形式・404の切り分け
• MkDocsの使い方｜Material for MkDocsの設定・日本語検索・GitHub Pages公開と2.0の注意
• SSGとは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準
• VercelとCloudflare Pagesの違い：Next.jsの動かし方・料金の増え方・商用条件で選ぶ【2026年10月】
• GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準