
2026/04/10 5:59
**WordPress から Jekyll(及び一般的な静的サイト生成器)への移行**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
概要
著者は、WordPress ブログを Jekyll 静的サイトへ完全に移行した過程と、その移行がコンテンツ作成速度と品質の向上につながる方法について記述しています。主な実施項目は次の通りです。
-
コンテンツ転送
WordPress から XML でエクスポートされた 288 件の投稿およびその他ページを Jekyll にインポートしました。Claude Code スクリプトが内容を公平性(equity)に配慮してフィルタリングしました。 -
ツール選択
著者の既存経験、成熟度、およびデータベースやアプリケーションサーバーを必要としない点から、Astro/Cloudflare CMS より Jekyll を採用しました。 -
AI支援開発スイート
Claude Code で構築した 9 つのカスタムツールがサイトを監査・最適化します(サイト構造、Lighthouse スコア、スキーマ生成、AEO、Open Graph プレビュー、コンテンツ類似性チェック、内部リンク提案、リダイレクト処理)。 -
セマンティック SEO
All‑MiniLM‑L6‑v2 エンベディングをローカルで使用し、トピックのクラスタリング、トピックテーブル生成、類似ペア報告書作成、検索関連性を向上させるセマンティックコア構築を行いました。 -
クライアントサイド検索
ビルド時に
ファイルを生成し、外部依存なしで約 3,000 ページまで 3 ms 未満のレイテンシで検索可能にしました。/search.json -
構造化データ(初日から)
Organization、WebSite、BreadcrumbList、FAQPage、BlogPosting、SoftwareApplication の JSON‑LD をフロントマターとテンプレート経由で自動挿入します。 -
モダン Web 標準
環境依存
、canonical タグ、Open Graph メタ、RSS フィード、GTM/Analytics(クッキー同意付き)、sitemap 生成(jekyll‑sitemap)を設定しました。robots.txt -
セキュリティヘッダー
CSP ヘッダーを 6 回のデプロイで段階的に洗練し、Cloudflare Analytics、Google Ads コンバージョントラッキング、Leaflet マップライブラリを許可しました。 -
デプロイワークフロー
本番およびプレビュー分岐は Cloudflare Pages 上で動作。
スクリプトがbuild.sh
を設定し、本番では開発ツールを除去、ステージングでは noindex ヘッダーを追加します。JEKYLL_ENV -
DNS マイグレーション
ドメインは Kinsta から Cloudflare Pages(
)へ移行。切り替え後に Screaming Frog を走らせ、ファビコン欠落などの問題を修正しました。www.demandsphere.com -
今後の最適化計画
100 KB 超の画像 65 件以上の圧縮、ブログ投稿のカテゴリ分け改善、内部リンク強化が予定されています。
インパクト
- ユーザーは読み込み速度向上、検索結果の精度向上、サイト挙動の信頼性を体感します。
- 開発者は AI ツールによる手作業削減で構築パイプラインがスリム化されます。
- 業界全体としては、性能と保守性から静的サイトジェネレーターの採用拡大が期待できます。
本文
WordPress から Jekyll(および一般的な静的サイトジェネレーター)への移行
WordPress から有名な静的サイトジェネレーターである Jekyll に移行した理由と方法に関する技術ノート。
なぜ移行を決めたのか?
最近、私たちは WordPress から Jekyll への移行を完了しました。この決定は主に以下の三つの要因によって動機付けられました。
- 好み – チームがより自然に使えるツールを求めていました。
- 速度 – WordPress はボトルネックになり、開発者を待たなければならず、その可用性に制限されることが多かったです。
- 変更の容易さ – Jekyll の静的構造はデータベースやアプリケーションサーバーを必要とせず、サイトを素早く変更できる点が魅力でした。
Jekyll(または Astro)のようなフレームワークは、AI の拡散、Markdown が LLM の共通言語となる流れ、ヘッドレスサイトへの移行という現在のトレンドに合致しています。WordPress は脆弱性がある場合がありますが、信頼できるホスティングを利用すれば多くのリスクは軽減されます。
Jekyll を選択したアーキテクチャ上の決定
Cloudflare の新しい CMS フレームワーク(Astro ベース)は有力候補でしたが、私たちは成熟度と既存の知識を重視し Jekyll を採用しました。
静的サイトジェネレーターはデータベースやアプリケーションサーバーを持たず、HTML テンプレート、インクルード、レイアウトファイル、設定ファイル、Markdown だけで構成されます。メタデータは YAML フロントマターに格納します。
layout: post title: "WordPress から Jekyll(および静的サイトジェネレーター)への移行" description: "WordPress から有名な静的サイトジェネレーターである Jekyll に移行した理由と方法に関する技術ノート。" date: 2026-04-09 author: Ray Grieselhuber permalink: /blog/rebuilding-demandsphere-with-jekyll-and-claude-code/ tags: - Engineering - AI Search
投稿は
_drafts に作成し、公開準備ができたら _posts に移動します。
288 本の WordPress ブログ記事を移行する
最大の課題はコンテンツの移行でした。15 年以上にわたる投稿がありますが、最も価値のあるものだけを残す必要がありました。GSC ツールを使い、高い評価を持つページを特定し、低価値のコンテンツを除外して削除しました。
WordPress の XML エクスポートは出発点として利用しました。Claude Code が各ページの価値を迅速に分析し、効率的にフィルタリングできるよう支援しました。画像の移行には追加スクリプトが必要でしたが、主にインポート/エクスポート作業で済みました。
Claude Code で実現した AI アシスト開発
Claude Code を活用して外部リソースを雇わずに移行を完了できました。複数のセッション、
CLAUDE.md、さまざまな .md ファイルを使いプロジェクトを整理しました。
主な成果物:
- 9 つの開発ツール をリポジトリに直接組み込み、それぞれ専用の監査スクリプト(例:
、サイト構造スクリプト)で管理。lighthouse.js - Site Structure Tool – 軽量な Screaming Frog の代替で、欠落または重複メタデータ、URL 配置ミスを検出。
- Lighthouse Auditor – ページ速度とパフォーマンス指標を向上;静的ホスティングにより実装が容易。
- Schema, AEO, Schema Details, Open Graph Preview – 構造化データとソーシャル共有の外観を監査・プレビューするツール。
- Content Similarity (Topic Clusters & Tables) –
エンベディングで内容をセマンティックにクラスタリングし、重複または類似投稿を特定。all-MiniLM-L6-v2 - Internal Linking Auditor – 埋め込み情報に基づき内部リンク構造を最適化。
- Redirects Tool – 重要なリダイレクトが漏れないよう保証。
これらのツールで、仕上げ作業と優先タスクのロードマップが明確になりました。
外部依存なしで実現したクライアント側検索
Jekyll はビルド時に
search.json を生成します。ここには各ページのタイトル、URL、内容(最大 400 文字)、タグ、日付、タイプが含まれます。検索ページはこの単一 JSON ファイルを取得し、ブラウザ内でサブストリングマッチングを行い、メタデータにスコア(例:タイトル×10、タグ×5)を付与します。結果は 30 件に制限。
現在の統計:398 エントリ;最適化前に 2,500〜3,000 ページ まで拡張可能です。推定レイテンシは 5,000 ページでも < 3 ms です。
SEO アーキテクチャ
初日から構造化データを追加しました:
とOrganization
をすべてのページにWebSite- ホーム以外のページには
BreadcrumbList - FAQ コンテンツがあるページは自動生成されたフロントマターから
FAQPage - ブログ投稿には
BlogPosting - 製品ページには
SoftwareApplication
JSON‑LD を手作業で編集する必要はありませんでした。現在、128 ページに 470 件以上の FAQ エントリ が存在します。
その他の SEO 機能:
- Canonical タグ、Open Graph メタ、および RSS フィードは
を使って正しい環境を解決。site.url
は環境依存:ステージングでは Screaming Frog と Sitebulb 以外のボットをブロックし、本番ではすべて許可。robots.txt- GTM と Google Analytics はユーザー同意後にのみロード(ステージングでは無効)。
によるサイトマップ生成;手動メンテナンス不要。jekyll-sitemap
Content Security Policy (CSP) には Cloudflare アナリティクス、Google Ads コンバージョントラッキング、および Leaflet マップライブラリを許容するために複数回更新が必要でした。
本番切り替え
同一リポジトリから Cloudflare Pages 上で二つの環境を稼働:
- Production:メインブランチ。
ディレクトリを削除し、サイトマップを保持。dev-tools - Staging:その他のブランチ。サイトマップを削除し、noindex ヘッダーを追加。
DNS 切替は簡単でした。
www.demandsphere.com をカスタムドメインとして追加するだけで Kinsta から Pages への CNAME が切り替わりました。切替後に Screaming Frog のクロール結果では、Google 検索結果に favicon が欠落していることが判明(ルート /favicon.ico が 404;PNG サイズが小さすぎ)。96×96 と 48×48 PNG を追加し、ウェブマニフェストと多サイズ ICO をルートに配置しました。
今後の取り組み
- 65 本以上の画像(> 100 KB)を最適化。
- 移行した 288 本のブログ投稿のカテゴリ分けを改善(現在は「Blog」タグのみ)。
- 内部リンク、スキーマカバレッジ、およびコンテンツクラスタリングを継続的に洗練。
- ページ数が 3,000 を超える場合に備え、検索機能の拡張を検討。
全体として、移行には満足しています。新しいコンテンツアイデアをこれまで以上に高速かつ高品質で実装できるようになりました。