Vercel Subdirectory Reverse Proxyはどう動くのか？

メインドメイン（negabaro.com）はVercelでNext.jsを運用しています。
ブログコンテンツ（/blog/）は別サーバー*でレンダリングします。

VercelのNext.js MiddlewareがNextResponse.rewrite()でリクエストをプロキシし、Hostヘッダーをオリジンサーバーのホストに書き換えます。
ブラウザURLはnegabaro.com/blog/...のまま維持されるため、ドメイン権威が分散しません。

なぜサブディレクトリか

Googleはサブドメイン（blog.example.com）を別サイトとして扱います。
一方、サブディレクトリ（example.com/blog）は同一サイトの一部として認識します。

ブログで蓄積したバックリンク・トラフィック・コンテンツ権威がメインドメインに直接合算されます。

バックエンドに依存しないパターン

動的サーバー（Rails on DigitalOcean）でも静的サイト（Jekyll on GitHub Pages）でも同じプロキシパターンで統合できます。

違いはアセットURL処理だけです：

• Rails: asset_host Procでリクエスト時に動的決定

• Jekyll: _config.ymlの{{ site.url }}でビルド時に静的確定

現実的な選択: Jekyllはサブドメインのまま

サブディレクトリプロキシがSEOに最適ですが、Jekyll（GitHub Pages）のURLパス構造を合わせる作業は面倒です。

Jekyllのpermalink構造をメインドメインの/blog/archive/...パスと一致させるには：

• permalink、baseurl設定の変更

• 内部リンクの全面書き換え

そのためJekyllはサブドメイン（negabaro.github.io）のまま、canonical/OGP/アセット絶対URLだけ設定してSEOメリットだけ得る方式を選びました。

サブディレクトリほどのドメイン権威統合はできませんが、canonicalによる重複防止とアセット絶対URLによるプロキシ互換性は確保されます。

Vercel Edgeフロントエンドの性能メリット

VercelのグローバルEdge Networkがプロキシの前段でキャッシュ + CDNの役割を果たします。

• s-maxage=60 → 60秒間Edgeから即座に応答

• stale-while-revalidate=300 → キャッシュ期限後も5分間staleレスポンスを先に配信、バックグラウンドで更新

ユーザーは世界中どこからでもVercel Edgeのキャッシュ済みHTMLを受け取るため、オリジンサーバーの地理的位置に関係なく高速なTTFBを得られます。

デプロイの独立性

各オリジンサーバーは完全に独立してデプロイされます。

• Railsサーバーを再デプロイしてもJekyllブログに影響なし（逆も同様）

• Vercel Edgeキャッシュがオリジンのダウンタイムを吸収 → 短いデプロイ中断はユーザーに見えない

• 新カテゴリ追加はVercel Middlewareにrewriteルール1行追加だけ