2025年にテックブログを運営するなら、 「速さ」はもはや前提条件 です。Astroのようなフレームワークのおかげで、Lighthouseで満点を取ることは難しくなくなりました。新たな戦場は、 「発見可能性（Discovery）」「エンゲージメント」、そして「インフラとの整合性」 です。

当ブログでは最近、アーキテクチャの全面的な刷新を行いました。これは単なる見た目のリニューアルではなく、現代のSEO基準とユーザーの期待に応えるための体系的な「5フェーズ」のエンジニアリングロードマップでした。

この記事は、スタックをどのように現代化したかを記録した、正確なエンジニアリングログです。

以下は、刷新後のアーキテクチャ概略図です。メインスレッドを保護するために、重い処理（GA4）をWorkerに逃がし、動的データ（コメント）をエッジに近いDBから取得しています。

Phase 1: 技術的基盤（The Technical Foundation）

新機能を追加する前に、ランキングを損なう「見えない負債」を解消する必要がありました。

1. 正規URLの標準化（Canonical Standardization）

検索エンジンは曖昧さを嫌います。もし /blog/post/ と /blog/post が両方存在していると、評価が分散してしまいます。そこで、厳格な「トレイリングスラッシュなし（No Trailing Slash）」ポリシーを適用しました。

変更点:

1. Astro Config : trailingSlash: "never" を明示的に設定。
2. Canonical Logic : BaseHead コンポーネントを更新し、生成されるURLから末尾のスラッシュを削除。

export default defineConfig({
 // ...
 trailingSlash: "never",
 build: {
 format: "file",
 },
});

2. Partytownによるブロッキングゼロの分析

Google Analytics 4 (GA4) は重いです。これをメインスレッドで読み込むことは、パフォーマンス上の「罪」と言えます。対策として Partytown を導入し、GA4をWeb Workerへとオフロードしました。

3. 高度な構造化データ（JSON-LD）

「How-to」クエリで上位表示されるには、優れたテキストだけでは不十分です。構造化データが必要です。JsonLd.astro コンポーネントを拡張し、コンテンツタイプに応じて FAQPage や HowTo スキーマを動的に出力できるようにしました。

Phase 2: エンゲージメントと主権（Engagement & Sovereignty）

長年、開発者ブログはDisqusやGiscusといった「借地」のコメントシステムに依存してきました。当ブログでは、このデータの主権を取り戻すことにしました。

Astro DBによるネイティブコメント機能

GitHub Discussions APIを利用するGiscusから、ネイティブな Astro DB (LibSQL) ソリューションへ移行しました。

なぜか？

• パフォーマンス : サードパーティのiframe読み込みがゼロに。
• コントロール : データは自分たちのものです。コメント投稿者にGitHubアカウントを強制する必要もありません（将来的にゲスト投稿を許可する場合など）。
• UI : 継ぎ接ぎのウィジェットではなく、デザインシステムとシームレスに統合できます。

以下はAstro DBの概念を解説している素晴らしい動画です。

国際SEO（i18n）

このブログは日本、米国、中国の読者にサービスを提供しているため、標準的なSEOだけでは不十分です。そこで、自動化された hreflang 生成を実装しました。

{slug && (
 <>
 <link rel="alternate" hreflang="ja" href={new URL(`/blog/${slug}`, site).href} />
 <link rel="alternate" hreflang="en" href={new URL(`/en/blog/${slug}`, site).href} />
 <link rel="alternate" hreflang="zh" href={new URL(`/zh/blog/${slug}`, site).href} />
 <link rel="alternate" hreflang="x-default" href={new URL(`/blog/${slug}`, site).href} />
 </>
)}

これにより、Googleは米国のユーザーには英語版を、東京のユーザーには日本語版を適切に提供できます。

Phase 3: ディスカバリー・エンジニアリング

404ページは行き止まりではいけません。そこは「転換点」であるべきです。

検索ファーストな404ページ

404レイアウトを強化し、目立つ Search Dialog（検索ダイアログ） を配置しました。迷子になったユーザーを直帰させるのではなく、「何をお探しでしたか？」と誘導します。

RSSフィードの分割

以前のRSSフィードは、言語が混在する「垂れ流し」状態でした。これはユーザーにとってノイズです。そこで、ロジックを以下のように分割しました：

• /rss.xml: 日本語（デフォルト）
• /en/rss.xml: 英語のみ
• /zh/rss.xml: 中国語のみ

これにより、ユーザーの購読設定を尊重し、解除率を減らすことができます。

Phase 4: SPA体験（View Transitions）

Astroの View Transitions は、静的サイトをネイティブアプリのように感じさせます。しかし、複雑さも伴います。window.onload や DOMContentLoaded に依存するスクリプトは、一度だけ実行され、ページ遷移後に壊れてしまいます。

開発秘話：コピーボタンの戦い

「コードをコピー」ボタンは、ハードリフレッシュ後は動作しましたが、リンクをクリックして遷移した後には死んでいました。修正策は、ライフサイクルイベントを astro:page-load に移行することでした。

// Before (ページ遷移で壊れる)
// document.addEventListener("DOMContentLoaded", () => { ... });

// After (View Transitionsに対応)
document.addEventListener("astro:page-load", () => {
 const codeBlocks = document.querySelectorAll("pre");
 // ... hydration logic
});

Phase 5: コンテンツ・エンジニアリング

最後に、コンテンツのFrontmatterをデータベースとして扱うことにしました。

AIサマリーフィールド

コンテンツスキーマに ai_summary 配列フィールドを追加しました。

// src/content/config.ts
ai_summary: z.array(z.string()).optional(),

このフィールドが（私たち、あるいはAIエージェントによって）入力されると、AISummary コンポーネントが自動的に記事冒頭に要約をレンダリングします。これは読者の時間を尊重し、スキャナビリティ（読み流しやすさ）を向上させます。

結論

ブログの現代化とは、単にCSSを書き換えることではありません。 「ユーザーの状態（言語、購読）」 と 「マシンの要件（スキーマ、速度）」 を尊重するということです。

当ブログがどのようにこのプラットフォームを進化させ続けているか、他のエンジニアリングログもぜひチェックしてください。