GitHub PagesのURLはどこで確認する？表示されない原因・形式・404の切り分け

GitHub Pagesで公開したサイトのURLは、リポジトリのSettingsにあるPagesの画面で確認できます。ただしURLの形はサイトの種類で決まり、リポジトリ名の変更やカスタムドメインの設定で変わります。パスは大文字と小文字を区別するため、「綴りは合っているのに404」という詰まり方も起きます。

この記事では、URLを確認する3つの方法、画面にURLが出ないときの原因、URL形式、URLが変わる条件、404とDNSの切り分け、アクセス解析の入れ方までを、GitHub公式ドキュメントと2026年10月20日の実測値をもとに整理しました。GitHub Pagesの概要・料金・制限はGitHub Pagesとは？料金と無料の範囲・容量制限・商用利用とSEO設定【2026年】で扱っています。

まとめ

• 公開URLは、リポジトリのSettings→Pagesの「Visit site」で確認できます。プッシュから反映までは最大10分かかります。
• URLの形はユーザーサイト・組織サイトが https://owner.github.io、プロジェクトサイトが https://owner.github.io/repository です。Enterprise Cloudで非公開にしたサイトは *.pages.github.io の固有サブドメインになります。
• 画面にURLが出ないときは、公開元（Source）が未設定か、Actionsのデプロイが成功していないか、Freeプランのprivateリポジトリかを疑います。
• 画面を開かずに取るなら gh api repos/OWNER/REPO/pages --jq .html_url です。2026年10月20日の実測では、認証なしの呼び出しは公開サイトでも404だったので、ログイン済みのCLIで呼びます。
• パスは大文字小文字を区別し、ホスト名は区別しません。html_url が http:// で返るサイトはHTTPSが強制されておらず、httpのまま表示されます。
• URLはリポジトリ名の変更、公開範囲の切り替え、カスタムドメインの追加・削除で変わります。公開を止めるときはDNSレコードも外さないと、サブドメインを乗っ取られる余地が残ります。
• Pagesにアクセス解析機能はありません。GA4とSearch Consoleを自分で入れ、Jekyllでは JEKYLL_ENV=production の指定漏れに注意します。

GitHub PagesのURL形式とサイト種別

GitHub公式の「GitHub Pagesとは」は、サイトを「ユーザー・組織サイト」と「プロジェクトサイト」の2種類に分けています。URLの形はこの種類で決まります。Enterprise Cloudの組織だけは、プロジェクトサイトを非公開で公開でき、そのときは別のホスト名になります。

ownerはユーザー名またはOrganization名です。ユーザー・組織サイトのリポジトリ名は owner.github.io 以外にできず、1アカウントにつき1つしか作れません。部署ごとにトップレベルのサイトを分けたい組織は、プロジェクトサイトを並べるか、カスタムドメインのサブドメインで分けることになります。

非公開のプロジェクトサイトは、公式の「サイトの可視性を変更する」によると、リポジトリの読み取り権限を持つ人だけが閲覧できます。ホスト名が *.pages.github.io の固有サブドメインになるのは、組織内の別リポジトリと同じオリジンを共有させないためです。Enterprise Managed Usersを使う企業では、Pagesサイトは非公開でしか公開できません。組織サイトそのものは非公開にできない点も、公式に明記されています。

公開URLを確認する3つの方法

Settings→Pagesの「Visit site」

いちばん確実なのは画面での確認です。公式の「GitHub Pagesサイトを作成する」の手順は次のとおりです。

1. リポジトリ名の下にあるSettingsを開く（タブが見えなければ「…」のメニューから選ぶ）。
2. サイドバーの「Code, planning, and automation」でPagesを選ぶ。
3. 「GitHub Pages」の下に出る「Your site is live at」のURL、または「Visit site」をクリックする。

プッシュしてから公開に反映されるまでは最大10分かかります。1時間経っても変わらなければ、伝送の遅れではなくビルドの失敗を疑ってください。

GitHub Actionsのデプロイ結果（page_url）

Actionsで公開しているなら、URLはデプロイのたびに出力されます。actions/deploy-pages のaction.ymlは出力 page_url を「URL to deployed GitHub Pages」と定義しており、公式のワークフローテンプレートはこれを github-pages 環境のURLに渡しています。ワークフロー実行画面のdeployジョブに、このURLが表示されます。

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

gh apiによる公開URL（html_url）の取得

複数のリポジトリのURLをまとめて調べるときや、スクリプトに組み込むときは REST APIの「Get a GitHub Pages site」を使います。応答の html_url が公開URLです。2026年10月20日にGitHub CLIで実行した結果を示します。

$ gh api repos/squidfunk/mkdocs-material/pages --jq '.html_url, .https_enforced, .build_type'
https://squidfunk.github.io/mkdocs-material/
true
workflow

$ gh api repos/jekyll/minima/pages --jq '.html_url, .https_enforced, .build_type'
http://jekyll.github.io/minima/
false
legacy

$ curl -s -o /dev/null -w "%{http_code}\n" https://api.github.com/repos/jekyll/minima/pages
404

読み取れることは3つあります。1つ目は認証の有無です。同じ日に認証なしのcurlで呼ぶと、APIバージョンのヘッダーを付けても、公開中のmkdocs-materialとminimaの両方で404が返りました。gh auth login 済みのCLIか、トークン付きで呼ぶのが確実です（公式ドキュメントは、OAuthアプリのトークンとクラシックの個人アクセストークンに repo スコープを求めています）。2つ目は build_type で、legacy はブランチからの公開、workflow はActionsからの公開です。

3つ目が見落としやすい点です。html_url が http:// で返るのは https_enforced が false のサイトで、curlで http://jekyll.github.io/minima/ を開くと301ではなく200がそのまま返りました。https_enforced が true のmkdocs-materialは、httpでのアクセスが301でhttpsへ転送されます。公式のHTTPSの解説によると、自動でHTTPS配信されるのは2016年6月15日以降に作られた github.io のサイトです。それより古いサイトやカスタムドメインのサイトでhttpのURLが返ったら、Settings→Pagesの「Enforce HTTPS」にチェックを入れてください。

Pagesの画面にURLが表示されないときの原因

Settings→Pagesを開いても「Your site is live at」が出ない場合、サイトは今公開されていません。まだ一度も公開されていないか、公開を止めた・削除した状態です。確認する順番は次のとおりです。

• 公開元（Source）の未設定：「Build and deployment」のSourceで「Deploy from a branch」を選んだら、ブランチとフォルダを指定してSaveを押すまで公開は始まりません。ブランチは事前にリポジトリに存在している必要があります。
• Actionsのデプロイが未成功：SourceをGitHub Actionsにした場合、ワークフローが成功してデプロイが作られるまでサイトはありません。Actionsタブで失敗している実行がないかを見ます。
• Freeプランでprivateリポジトリ：GitHub FreeとGitHub Free for organizationsではpublicリポジトリからしか公開できません。privateリポジトリから公開するにはGitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのいずれかが必要です。
• プッシュした人の権限：ブランチから公開しているなら、管理者権限を持ち、メールアドレスを確認済みのユーザーが公開元にプッシュしている必要があります。
• GITHUB_TOKENによるコミット：GITHUB_TOKEN を使うActionsワークフローがプッシュしたコミットでは、Pagesのビルドが起動しません。
• 公開を止めた後：「Unpublish site」で止めたサイトは、新しいデプロイを作るまで戻りません（後述）。

Pagesの設定画面は配置が何度か変わっており、古い記事のスクリーンショットと見た目が違うことがあります。画面の位置ではなく「Your site is live at」という文言を探すと迷いません。

URLパスの大文字小文字と末尾スラッシュの実測挙動

Jekyllの公式テーマminimaのデモサイトに対し、2026年10月20日にcurlで応答コードを測りました。

詰まる原因はパスの綴りです。Minima のように1文字でも大文字が混じると404になります。プロジェクトサイトのパスにはリポジトリ名がそのまま入るので、My-Portfolio という名前で作ると、URLは /My-Portfolio/ になります。リポジトリ名は最初から小文字とハイフンで付けてください。後から変えるとURLが変わり、既存のリンクが切れます。

最後の行の404は障害ではありません。認証付きのAPIで jekyll/jekyll.github.io を引くと404で、jekyll Organizationには公開の組織サイト用リポジトリがありません。プロジェクトサイトしか持たないアカウントのルートURLは404のままが正常です。

サブディレクトリとindex.htmlのURL対応

ブランチから公開する場合、公開元に指定できるフォルダはリポジトリのルート（/）か /docs の2つだけです。GitHub Pagesは公開元のトップにある index.html をエントリーファイルとして探し、サブディレクトリのURLは公開元からの相対パスがそのまま反映されます。

docs/                  ← 公開元フォルダに指定
  index.html          → https://owner.github.io/repo/
  about.html          → https://owner.github.io/repo/about.html
  guide/
    index.html        → https://owner.github.io/repo/guide/
    setup.html        → https://owner.github.io/repo/guide/setup.html

各階層に index.html を置けば、/guide/ のようにファイル名を省いたURLで開けます。ユーザーサイト（owner.github.io リポジトリ）の中にフォルダを作っても同じで、quiz/index.html は https://owner.github.io/quiz/ になります。公式の作成手順は、入口のファイルとして index.html・index.md・README.md のいずれかを探すと説明しています（Markdownはビルドで index.html になります）。HTMLを直接置くなら名前は小文字の index.html にしてください。公式の404トラブルシューティングは Index.html や index.HTML では動かないと明記しています。

URLが変わる条件と公開停止の後始末

URLが変わる4つの操作

• リポジトリ名の変更：プロジェクトサイトのパスがそのまま変わります。公式の「リポジトリの名前を変更する」は、名前を変えると旧名へのアクセスは新名へ転送されるが、プロジェクトサイトのURLだけは例外だと明記しています。旧URLは404になります。
• リポジトリの公開範囲の切り替え：公式の404トラブルシューティングは、publicとprivateを切り替えるとPagesのURLが変わり、再ビルドまでリンクが切れると説明しています。GitHub Freeのアカウントでprivateに変えた場合は、公式の「リポジトリの可視性を設定する」のとおり、公開中のサイトが自動で公開停止になります。
• サイトの可視性の切り替え（Enterprise Cloud）：非公開にすると *.pages.github.io の固有サブドメインへ移ります。リポジトリ名をパスに含める前提でビルドしているジェネレーターは、設定の見直しが必要だと公式が注意しています。
• カスタムドメインの追加・削除：経路の切り替えだけでは再ビルドが走らず、トップページは開けても中のリンクが壊れることがあります。公式の対処は、コミット作者を確認したうえでカスタムドメインを入れ直し、再ビルドを起こす手順です。

運用中のサイトでこれらを行うなら、被リンクや社内ドキュメントの張り替えを同じ日に計画してください。公式も、Pagesサイトを持つリポジトリの名前を変える予定があるならカスタムドメインを使うよう勧めています。リポジトリ名を変えても外向きのURLが変わらないためです。URLを長く使うサイトは、最初からカスタムドメインで公開してください。

Unpublish siteで止めるときのDNSの扱い

公開を止めるには、Settings→Pagesの「Your site is live at」の横にある「…」から「Unpublish site」を選びます。公式の「サイトの公開を停止する」によると、現在のデプロイが削除されるだけでリポジトリの設定と中身は残ります。再開するには、Actionsならワークフローを再実行し、ブランチ公開なら公開元を設定して新しいコミットを入れます。

カスタムドメインを使っているサイトを止めるときは、DNSレコードも外してください。公式のカスタムドメインの解説は、サイトを無効にしたままDNSにカスタムドメインを残すと、第三者がそのサブドメインでサイトを公開できる危険があると警告しています。

カスタムドメインのDNSレコード設定

wwwサブドメインとapexドメインのレコード値

サブドメインはCNAMEレコードで owner.github.io を指します。ここにリポジトリ名を含めるのは誤りで、404の典型的な原因です。公式の「カスタムドメインの管理」に載っている値は2026年10月20日時点で次のとおりです。

# サブドメイン（www.example.com）
www   CNAME   owner.github.io

# apexドメイン（example.com）: A レコード
@     A       185.199.108.153
@     A       185.199.109.153
@     A       185.199.110.153
@     A       185.199.111.153

# apexドメイン: AAAA レコード（IPv6。A レコードと併設する）
@     AAAA    2606:50c0:8000::153
@     AAAA    2606:50c0:8001::153
@     AAAA    2606:50c0:8002::153
@     AAAA    2606:50c0:8003::153

apexドメインはA、ALIAS、ANAMEのいずれかで設定します。AAAAを使う場合も、IPv6の普及が遅いことを理由にAレコードの併設が強く推奨されています。非公開サイトでも、CNAMEの向き先は owner.github.io のままで、Pagesの画面に出る *.pages.github.io の固有サブドメインに向けてはいけません。*.example.com のようなワイルドカードレコードは、ドメインを検証していても乗っ取りの危険があるので使わないでください。DNSの設計に不安があればAmazon Route 53とは：DNS・ドメイン登録・ルーティング設計とAWS CLI構築手順を実装者目線で解説も参考になります。

順番も重要です。GitHub側にカスタムドメインを登録してからDNSを設定してください。DNSだけ先に向けると、そのサブドメインを第三者に使われる可能性があります。ブランチ公開ではカスタムドメインを保存した時点で公開元のルートに CNAME ファイルを追加するコミットが作られますが、Actionsで公開している場合は作られず、既存の CNAME ファイルも無視されます。手で置いた CNAME ファイルが効かないときは、SourceがGitHub Actionsになっていないかを確認し、Settings→Pagesの「Custom domain」に登録してください。

プロジェクトサイトへのドメイン継承

ユーザーサイトか組織サイトにカスタムドメインを設定すると、同じアカウントのプロジェクトサイトにも既定でそのドメインが使われます。ユーザーサイトのカスタムドメインが www.octocat.com なら、octo-projectリポジトリのサイトは www.octocat.com/octo-project で配信されます。個別のプロジェクトサイトだけ別ドメインにするには、そのリポジトリでカスタムドメインを設定して上書きします。Enterprise Cloudの非公開サイトのURLは、この継承の影響を受けません。

URLが404になる原因の切り分け

公式の404トラブルシューティングと突き合わせると、上から順に見るのが早いです。

• GitHubのStatusページ（githubstatus.com）で障害が出ていないか。
• 公開元のトップに index.html があり、ファイル名の大文字小文字が正しいか。Actionsで公開しているなら、アップロードしたアーティファクトの最上位に入っているか。
• URLのパスの大文字小文字が、リポジトリ名やフォルダ名と一致しているか。
• 公開元のブランチが実在するか。設定画面では任意のブランチを選べますが、404のトラブルシューティングはmainか既定ブランチを使うよう案内しています。絞り込めないときは既定ブランチに寄せてください。
• カスタムドメインのCNAMEが、リポジトリ名を含まず owner.github.io を指しているか。
• privateリポジトリから公開しているなら、GitHub Pro、GitHub Team、GitHub Enterprise Cloudの契約が有効か。失効すると404になり、契約を更新すれば自動で再デプロイされます。
• 非公開サイトで404が出るなら、ブラウザのキャッシュを消す。

トップページは開けるのにCSSや画像だけ404になる場合は、次のbase_pathの問題です。存在しないパスに独自のページを返したいときは、公開元のトップに 404.html を置きます。

プロジェクトサイトのbase_pathとジェネレーターの設定

プロジェクトサイトのURLには /repository が挟まります。CSSや画像を /assets/style.css のようなルート相対パスで書くとこの階層を飛ばし、読み込めなくなります。公式テンプレートは、actions/configure-pages の出力 base_path をビルドに渡してこれを避けています。以下は actions/starter-workflows のJekyll用テンプレートのbuildジョブを、2026年10月20日時点の最新メジャー版（checkout v7.0.1、configure-pages v6.0.0、upload-pages-artifact v5.0.0）に差し替えたものです。テンプレート本体はまだcheckout@v4・configure-pages@v5・upload-pages-artifact@v3のままです。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true
      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v6
      - name: Build with Jekyll
        run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"
        env:
          JEKYLL_ENV: production
      - uses: actions/upload-pages-artifact@v5

configure-pages のaction.ymlは、URLを分解した4つの値を出力します。フルURLの base_url、オリジンの origin、ホスト名の host、パス部分の base_path です。action.ymlの例示では、base_path はプロジェクトサイトなら /my-repo、ユーザーサイトなら空文字です。Jekyllは --baseurl で受け取った値を site.baseurl に入れますが、テンプレートに直書きした /assets/style.css は自動では書き換わりません。{{ "/assets/style.css" | relative_url }} のように relative_url フィルターを通したパスだけが /my-repo/assets/style.css になります。この書き方にしておけば、同じワークフローをどちらの種別にも使えます。upload-pages-artifact の既定のアップロード先は _site/ で、v4以降はドットで始まるファイルを除外します（.well-known を配信したいなら include-hidden-files: true を指定）。

Jekyll以外のジェネレーターをブランチ公開で使うなら、公開元のルートに空の .nojekyll を置いてJekyllのビルドを止めます。MkDocsでの具体例はMkDocsの使い方｜Material for MkDocsの設定・日本語検索・GitHub Pages公開と2.0の注意、ワークフローの書き方そのものはGitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方で扱っています。複数リポジトリのデプロイを社内で標準化したい場合は、弊社のDevOps・CI/CD導入支援でもワークフロー設計からご相談を受けています。

混同しやすいGitHubの3種類のURL

「GitHubのURLを確認したい」という検索には、リポジトリのURLとPagesのURLの取り違えが混じります。HTMLファイルを置いたのにページとして表示されないときは、開いているURLが次の3種類のどれかを確かめてください。

raw.githubusercontent.com のHTMLファイルをcurlで取得すると、2026年10月20日の実測で content-type: text/plain; charset=utf-8、x-content-type-options: nosniff、content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox が返りました。ブラウザはHTMLとして解釈せず、スクリプトも動きません。サイトとして見せたいなら、Pagesで公開して github.io のURLを使ってください。

github.io はGitHubがPublic Suffix Listに登録しているドメインで、owner.github.io ごとに別サイトとして扱われます。ブラウザは別アカウントの github.io サイトとCookieを共有しません。

アクセス解析の導入と計測されない原因

GA4タグの設置とJEKYLL_ENVの罠

GitHub Pagesにアクセス解析の機能はありません。公式は訪問者のIPアドレスをセキュリティ目的で記録すると明記していますが、そのログをサイト所有者が見る手段はありません。アクセス数を知るにはGA4を自分で入れます。素のHTMLなら、各ページの head 要素にGA4のタグを貼ります。

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

Jekyllのminimaテーマは、使う版によってGA4が計測できません。GitHub Pagesの依存関係一覧でブランチ公開に使われるminimaは2.5.1で、その _includes/google-analytics.html は旧来の analytics.js（ga('create', …)）を出力します。2026年10月20日時点の最新リリース2.5.2も同じで、gtag.js を出すのは未リリースのmasterブランチだけでした。_config.yml に google_analytics: G-XXXXXXXXXX と書いても、2.5.xではGA4にデータが届きません。

対処は、サイト側に同名の _includes/google-analytics.html を置き、上のgtag.jsのタグを書くことです。Jekyllはテーマより自サイトの _includes を優先するので、テーマを変えずに差し替えられます。もう1つの罠が環境変数で、minimaの head.html は jekyll.environment == 'production' のときだけこのファイルを読み込みます。ブランチ公開ではGitHubが本番として扱いますが、自前のActionsワークフローで JEKYLL_ENV: production を落とすと、タグがHTMLに一切入りません。数字がゼロのままなら、公開されたページのソースを開き、gtag/js?id=G- が出力されているかを確かめてください。

Search Consoleのプロパティ選択

Search Consoleでは、owner.github.io のDNSレコードを触れないため、DNSでの所有権確認が必要なドメインプロパティは使えません。URLプレフィックスプロパティを選び、HTMLファイルのアップロードかHTMLタグで確認します。カスタムドメインを設定済みなら、そのドメインのDNSを触れるのでドメインプロパティも選べます。登録後の見方はサーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】で解説しています。

よくある質問

GitHub PagesのURLはどこで確認できますか？

リポジトリのSettingsを開き、サイドバーの「Code, planning, and automation」からPagesを選ぶと、「Your site is live at」の後にURLが表示され、「Visit site」で開けます。表示されない場合は、公開元が未設定かデプロイが成功していません。

GitHub Pagesのドメインは何になりますか？

既定は owner.github.io です。ユーザー・組織サイトはこのドメインのルート、プロジェクトサイトは owner.github.io/repository で配信されます。Enterprise Cloudで非公開にしたサイトは *.pages.github.io の固有サブドメインです。

GitHub PagesのURLを作るにはどうすればいいですか？

リポジトリを作り、トップに index.html を置いてプッシュし、Settings→PagesのSourceで公開するブランチを選んでSaveを押します。最大10分ほどで https://owner.github.io/repository/ が発行されます。リポジトリ名を owner.github.io にすると、ルートの https://owner.github.io/ になります。

GitHub PagesのURLを変更できますか？

できます。プロジェクトサイトはリポジトリ名を変えるとパスが変わります。ユーザー・組織サイトはリポジトリ名がアカウント名に固定されるため、変えるならカスタムドメインを設定します。リポジトリ名を変えても旧URLから新URLへは転送されないので、リンクの張り替えを計画してから変えてください。

組織のGitHub Pagesはいくつ作れますか？

組織サイト（orgname.github.io）は1つのOrganizationにつき1つです。プロジェクトサイトはリポジトリごとに1つ作れるので、本数自体の上限はありません。トップレベルのサイトを複数持ちたい場合は、カスタムドメインのサブドメインで分けます。

関連記事

• GitHub Pagesとは？料金と無料の範囲・容量制限・商用利用とSEO設定【2026年】
• GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方
• MkDocsの使い方｜Material for MkDocsの設定・日本語検索・GitHub Pages公開と2.0の注意
• Cloudflare Pagesの使い方｜静的サイトの公開手順・独自ドメイン・商用利用とWorker
• サーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】