最終更新：2026-01-18
※生成AIにより自動的に生成した記事です。
報告
ss0832.github.ioは諸事情により、数か月後に閉鎖する。そのため、新規に静的ホスティングサービスを探した結果、CloudFlare Pagesに備忘録を移転可能であることが判明した。
新URL:ss0832-github-io.pages.dev
今後は、このURLにアクセスすることで備忘録を継続して利用可能となる。
以下は、ss0832.github.ioから新URLにリダイレクトさせるために行った内容に関して、生成AIに書かせた。
概要
クライアントサイド・リダイレクト（Client-side Redirect）は、サーバー側の設定（.htaccessやNginx設定など）を使用せず、HTMLファイル内のメタタグやJavaScriptを用いて、ユーザーを古いURLから新しいURLへ自動的に転送する手法である。
※Apacheの.htaccessやNginxの.confといったサーバーサイドの設定が使用不可能である。つまり301 Moved Permanentlyが使えない。そのため、Gemini(生成AI)と相談して、移転用のHTMLコードを提案していただきそれを用いる形とした。
構成例と主要要素
例1：リダイレクト用HTMLの基本構造
「このページは移動しました。自動的に転送されない場合はリンクをクリックしてください。」という従来の簡素な記述に加え、検索エンジンへの正規化指示とJavaScriptによるパス維持を含めた構成例である。
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Redirecting to new site...</title>
<link rel="canonical" href="https://new-site.example.com/">
<meta http-equiv="refresh" content="0; url=https://new-site.example.com/">
<script type="text/javascript">
window.location.replace("https://new-site.example.com" + window.location.pathname + window.location.search);
</script>
</head>
<body>
<p>Redirecting to <a href="https://new-site.example.com/">new-site.example.com</a>...</p>
</body>
</html>推奨される理由：meta refresh 単体ではSEO評価の引き継ぎが不完全になるリスクがあるため、canonical タグを併記することで検索エンジンに対して「恒久的な移転」であることを明示する。（備忘録兼自身のプログラムの検証結果を大量に載せているため、SEOを一切意識していないのでここまで行う必要はないとは個人的には思っている。）
例2：404ページへの応用
GitHub Pagesなどの静的ホスティングサービスでは、存在しないパスへのアクセスに対して 404.html が表示される。この仕様を利用し、上記の index.html と同一の内容を 404.html として配置する。
推奨される理由：これにより、トップページ以外の個別記事（例：/blog/article-1）への直接リンクから流入した場合でも、JavaScriptによってパス情報を維持したまま新ドメインの該当ページへ転送することが可能となる。
実装のポイント
Canonicalタグの必須化：新旧サイトの重複コンテンツ判定を防ぎ、旧サイトのドメイン評価（PageRank等）を新サイトへ適切に統合するために不可欠である。
window.location.replace の使用：href への代入ではなく replace メソッドを使用することで、ブラウザの履歴にリダイレクト前のURLを残さないようにし、「戻る」ボタンを押した際のループ現象を回避する。
補足ファイルの詳細な構造の説明
※本文では「だである調」でしたが、こちらは「ですます調」で書きます。
1. 文書構造の宣言
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">: 文字化けを防ぐための記述です。世界標準の文字コード（UTF-8）を指定しています。
2. タイトルとSEO評価の引き継ぎ（重要）
<title>Redirecting to new site...</title>
<link rel="canonical" href="https://new-site.example.com/"><title>...: ブラウザのタブや検索結果に表示されるタイトルです。一瞬しか表示されませんが、ユーザーに「転送中」であることを伝えます。
<link rel="canonical" ...>: **【SEOの要】**です。「カノニカル（正規）タグ」と呼ばれます。
意味: 「この古いページの評価（被リンクやドメインパワー）は、すべて href で指定した新しいURLのものとして扱ってください」とGoogle等の検索エンジンに指示します。これがないと、新旧サイトで評価が分散してしまう恐れがあります。
3. ブラウザ機能による強制転送（保険）
<meta http-equiv="refresh" content="0; url=https://new-site.example.com/">http-equiv="refresh": JavaScriptが無効な環境でも動作する、HTML標準の転送機能です。
content="0; ...": 「0秒後（即座）」に、「指定されたURL」へ移動せよ、という命令です。JavaScriptが動く前にこれが発動することもあります。
4. JavaScriptによる「賢い」転送（メイン機能）
<script type="text/javascript">
window.location.replace("https://new-site.example.com" + window.location.pathname + window.location.search);
</script>window.location.replace(...):
単なる移動（href）ではなく、**「履歴の上書き（replace）」**を行います。
メリット: ユーザーが転送先でブラウザの「戻る」ボタンを押した際、この「転送ページ」に戻ってきて無限ループするのを防ぎます。
... + window.location.pathname:
パスの維持を行います。例えば、古いサイトの .../blog/article-1 にアクセスした場合、新しいサイトのトップページではなく、きちんと .../blog/article-1 に転送します。
... + window.location.search:
パラメータの維持を行います。URLの末尾に付く ?id=123 などの情報も捨てずに引き継ぎます。
5. 最後のセーフティネット（手動リンク）
</head>
<body>
<p>Redirecting to <a href="https://new-site.example.com/">new-site.example.com</a>...</p>
</body>
</html><p>... <a href="...">...</a> ...</p>:万が一、JavaScriptも動かず、Meta Refreshもブロックされるような極めて特殊な環境（あるいはガラケーやテキストブラウザなど）のための**「手動クリック用のリンク」**です。
通常は表示された瞬間に転送されるため、人の目に触れることはほとんどありませんが、システムの堅牢性を担保するために必須です。
まとめ：本文のHTMLファイルの挙動
このコードは「3段構え」のロケットのような構造になっています。
-
第1段（JS）: パスや履歴を考慮した、最もユーザー体験の良い転送を試みる。
-
第2段（Meta）: JSが動かなくても、0秒で強制的に転送する。
-
第3段（Link）: 全てが失敗しても、クリック一つで移動できるようにする。
さらに、裏側で Canonicalタグ が検索エンジンに対して「私が本物の新しい住所です」と宣言し続けています。
補足：「CloudFlare Pagesを使う理由」をGeminiに解説させた。
1. 圧倒的な「エッジ」の優位性（パフォーマンス）
Github Pages(GP)とCloudFlare Pages(CFP)の最大の違いは、コンテンツを配信するサーバーの**「物理的な距離」**です。
GitHub Pages(GP): コンテンツは特定の場所（オリジン）から配信されるため、地理的に遠いユーザーには遅延（レイテンシ）が発生しやすい。
Cloudflare Pages(CFP): 世界中にあるデータセンター（エッジネットワーク）にコンテンツがキャッシュされ、ユーザーに**「最も近い場所」**から配信される。
根拠: Cloudflareのグローバルネットワークは世界330都市以上に展開されており、世界のインターネット接続人口の95%から50ミリ秒以内の距離にある。
結果: TTFB（Time To First Byte：最初の1バイトが届くまでの時間）が劇的に短縮される。
2. サーバーサイド設定の制御（柔軟性）
HTTPレスポンスヘッダーの制御: _headers ファイルを置くだけで、セキュリティヘッダー（HSTS, X-Frame-Options）やキャッシュポリシー（Cache-Control）を細かく設定可能。
サーバーサイド・リダイレクト: _redirects ファイルにより、ステータスコード 301（恒久的な移動）や 302（一時的な移動）を伴う真のリダイレクトが可能。
メリット: 「HTML読み込み後のJS転送（クライアントサイド）」ではなく、通信レベルでの即時転送が可能になり、SEO評価の損失リスクを極限までゼロにできる。
3. CI/CDパイプラインの高速性とプレビュー機能（開発体験）
高速なビルド: GitHub Actionsを経由せずとも、Cloudflare側のビルド環境が直接リポジトリを監視し、高速にデプロイを行う。
プレビューデプロイ: main ブランチ以外へのプッシュ（Pull Request作成時など）に対して、本番環境とは別の固有URLを自動生成する。
メリット: 記事を公開する前に、実際の表示崩れがないか、数式（LaTeX）が正しくレンダリングされているかを「本番と同じ環境」で検証できる。
4. セキュリティと可用性（堅牢性）
DDoS対策: 世界最大級のネットワーク容量を持つため、突発的なアクセス集中や攻撃を受けてもサイトがダウンしない（Unmetered Bandwidth）。
プライバシー重視の解析: Google Analyticsとは異なり、Cookieを使用せず、GDPRなどの法規制に準拠した「Cloudflare Web Analytics」が無料で利用可能。ユーザーの追跡を行わず、純粋なアクセス統計のみを取得できる。