---
title: "GitHub PagesのURLはどこで確認する？表示されない原因・形式・404の切り分け"
url: "https://www.issoh.co.jp/tech/details/4397/"
published: 2024-12-04
updated: 2026-10-20
categories: ["GitHub"]
publisher: "株式会社一創"
---

# 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年】](/tech/details/5875/)で扱っています。

## まとめ

- 公開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とは」](https://docs.github.com/ja/pages/getting-started-with-github-pages/what-is-github-pages)は、サイトを「ユーザー・組織サイト」と「プロジェクトサイト」の2種類に分けています。URLの形はこの種類で決まります。Enterprise Cloudの組織だけは、プロジェクトサイトを非公開で公開でき、そのときは別のホスト名になります。

| 種別            | リポジトリ名          | 既定のURL                             | 作成上限               |
| ------------- | --------------- | ---------------------------------- | ------------------ |
| ユーザー・組織サイト    | owner.github.io | https://owner.github.io            | 1アカウント1サイト         |
| プロジェクトサイト     | 任意              | https://owner.github.io/repository | 1リポジトリ1サイト         |
| 非公開のプロジェクトサイト | 任意（組織所有）        | 固有のサブドメイン.pages.github.io          | Enterprise Cloudのみ |

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

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

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

### Settings→Pagesの「Visit site」

いちばん確実なのは画面での確認です。[公式の「GitHub Pagesサイトを作成する」](https://docs.github.com/ja/pages/getting-started-with-github-pages/creating-a-github-pages-site)の手順は次のとおりです。

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」](https://docs.github.com/ja/rest/pages/pages)を使います。応答の `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://docs.github.com/ja/pages/getting-started-with-github-pages/securing-your-github-pages-site-with-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で応答コードを測りました。

| リクエストしたURL                                 | 応答  | 意味           |
| ------------------------------------------ | --- | ------------ |
| https://jekyll.github.io/minima/           | 200 | 正規の形         |
| https://jekyll.github.io/minima            | 301 | スラッシュ付きへ転送   |
| https://jekyll.github.io/minima/index.html | 200 | ファイル指定は転送なし  |
| https://jekyll.github.io/Minima/           | 404 | パスは大文字小文字を区別 |
| https://JEKYLL.github.io/minima/           | 200 | ホスト名は区別しない   |
| https://jekyll.github.io/                  | 404 | 組織サイトが未作成    |

詰まる原因はパスの綴りです。`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トラブルシューティング](https://docs.github.com/ja/pages/getting-started-with-github-pages/troubleshooting-404-errors-for-github-pages-sites)は `Index.html` や `index.HTML` では動かないと明記しています。

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

### URLが変わる4つの操作

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

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

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

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

カスタムドメインを使っているサイトを止めるときは、DNSレコードも外してください。[公式のカスタムドメインの解説](https://docs.github.com/ja/pages/configuring-a-custom-domain-for-your-github-pages-site/about-custom-domains-and-github-pages)は、サイトを無効にしたままDNSにカスタムドメインを残すと、第三者がそのサブドメインでサイトを公開できる危険があると警告しています。

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

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

サブドメインはCNAMEレコードで `owner.github.io` を指します。ここにリポジトリ名を含めるのは誤りで、404の典型的な原因です。[公式の「カスタムドメインの管理」](https://docs.github.com/ja/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site)に載っている値は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構築手順を実装者目線で解説](/tech/details/15471/)も参考になります。

順番も重要です。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の注意](/tech/details/3675/)、ワークフローの書き方そのものは[GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/)で扱っています。複数リポジトリのデプロイを社内で標準化したい場合は、弊社の[DevOps・CI/CD導入支援](/service/system/devops/)でもワークフロー設計からご相談を受けています。

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

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

| URL                                    | 中身               | HTMLの表示          |
| -------------------------------------- | ---------------- | ---------------- |
| github.com/owner/repo                  | リポジトリの画面         | ソースとして表示         |
| raw.githubusercontent.com/owner/repo/… | ファイルの生データ        | されない（text/plain） |
| owner.github.io/repo/                  | GitHub Pagesのサイト | される              |

`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](https://publicsuffix.org/list/public%5Fsuffix%5Flist.dat)に登録しているドメインで、`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の依存関係一覧](https://pages.github.com/versions.json)でブランチ公開に使われる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年時点】](/column/details/17246/)で解説しています。

## よくある質問

### 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年】](/tech/details/5875/)
- [GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方](/tech/details/2497/)
- [MkDocsの使い方｜Material for MkDocsの設定・日本語検索・GitHub Pages公開と2.0の注意](/tech/details/3675/)
- [Cloudflare Pagesの使い方｜静的サイトの公開手順・独自ドメイン・商用利用とWorker](/tech/details/3438/)
- [サーチコンソールとは？できること・設定手順とSEO改善への使い方【2026年時点】](/column/details/17246/)

---

出典: [GitHub PagesのURLはどこで確認する？表示されない原因・形式・404の切り分け](<https://www.issoh.co.jp/tech/details/4397/>)（株式会社一創）