WordPressを静的ウェブサイトに変換してAWSでホスティングする方法

本記事では、ローカル環境に構築したWordPressサイトを、静的ウェブサイトジェネレーターを使ってAWSにホスティングする方法を解説します。

この方法には以下のような様々なメリットがあります。

ブログ執筆の際はWordPressの便利な機能が使えるため、HTMLコードを意識することなく記事作成に集中できます。
ホスティングは静的ウェブサイトに変換し、CDN（CloudFront）も使うため、非常に高速な配信が可能です。
WordPress本体を外部公開しないため、動的サイト特有のセキュリティ対策（本体やプラグインの頻繁なアップデート、不正アクセス対策など）が不要になります。
非常に安価（月額100円前後～）にサイトをホスティングできます。

なお、本記事はwordpress.comからサイトを移行する方法の2番目のステップとしても位置づけられますが、別のホスティングプロバイダーからの移行や、新規ブログを静的サイトとしてAWSにホスティングする場合でも参考になるよう、汎用的に解説します。

WordPressでの事前準備
- Google Analytics設定
- 記事コメントを無効化
- お問い合わせフォームの変更
AWS S3バケット作成
静的サイトジェネレーター設定 (Simply Static)
- ローカル環境での静的サイト確認
- 相対URLで静的サイト生成
- S3へのアップロード
CloudFrontディストリビューション作成
- URLリライト用CloudFront関数の追加
ドメイン設定 (Route 53, ACM)
- AWS Route 53でホストゾーン作成
- AWS Certificate ManagerでTLS証明書作成
- CloudFrontとドメインの関連付け・テスト
本番公開と仕上げ
- ネームサーバーをRoute 53に変更
- XMLサイトマップ作成
- robots.txt作成
- 絶対URLで静的サイトを更新
- ルートドメインとwwwのリダイレクト設定
まとめ

WordPressでの事前準備

静的サイトを生成する前に、ローカル環境のWordPressでいくつかの事前準備を行います。

Google Analytics設定

インターネット上にあるWordPressサイトであれば「Site Kit by Google」プラグインが便利ですが、ローカル環境では設定がうまくいかないことが多いため、「Simple Custom CSS and JS」プラグインでGAタグを手動で埋め込む方法がおすすめです。

プラグインをインストールし、左メニューの Custom CSS & JS を選択し、Add HTML Code ボタンをクリックします。（Add JS Code ボタンもありますが、<script> タグが編集できないため、Google Analyticsコードには不向きです）

Google Analyticsの管理ページで発行したGAタグ（測定ID G-XXXXX のものなど）のコードを貼り付け、Publish ボタンを押して保存します。

記事コメントを無効化

静的サイトではWordPressのコメント機能は動作しないため、無効化します。

新規記事のコメントを無効化

WordPressの左メニューから Settings -> Discussion を選択し、Allow people to submit comments on new posts のチェックを外します。

既存記事のコメントを無効化

Posts メニューで全ての記事にチェックを入れ、Bulk actionsから Edit を選択して Apply ボタンを押します。表示された設定で Comments セレクトボックスを Do not allow に変更し、Update ボタンをクリックします。

お問い合わせフォームの変更

WordPressのフォームプラグイン（Contact Form 7など）を使っている場合、静的サイトでは機能しません。別のソリューションに切り替える必要があります。

本記事ではGoogleフォームを使ってフォームを作成し、カスタムHTMLブロックにiframeで埋め込む方法を紹介します。

Googleフォームにてフォームを作成します。
Googleフォーム上部のドロップダウンメニューより、「HTMLを埋め込む」を選択し、表示されたiframeのHTMLコードをコピーします。
WordPressのお問い合わせページの編集画面にて Custom HTML ブロックを追加し、コピーしたHTMLコードを貼り付けます。

AWS S3バケット作成

静的サイトのファイルを格納するためのS3バケットを以下の設定で作成します。

バケットタイプ：汎用
バケット名：サイトのドメインと同じ名前（例：ドメインがexample.comならバケット名もexample.com）。
オブジェクト所有者：ACL 無効
このバケットのブロックパブリックアクセス設定：パブリックアクセスをすべてブロック
バケットのバージョニング：無効にする
暗号化タイプ：Amazon S3 マネージドキーを使用したサーバー側の暗号化 (SSE-S3)
オブジェクトロック：無効にする

注）以前はS3の「静的ウェブサイトホスティング機能」を有効にする方法が主流でしたが、現在はCloudFrontのオリジンアクセスコントロール（OAC）を使い、S3バケット自体は非公開にする方法がベストプラクティスです。

静的サイトジェネレーター設定 (Simply Static)

静的サイトジェネレーターには「Simply Static」プラグインを使います。無料版と有料版がありますが、本記事では無料版を使います。プラグインをインストールして有効化してください。

ローカル環境での静的サイト確認

WordPressメニューから Simply Static -> Settings -> General ページを開き、Replacing URLs で Offline Usage を選択します。この設定はサイト上のURLをファイルシステムパス（file://...）に書き換えるため、本番デプロイには使えませんが、ローカルでの動作確認に最適です。

次に Simply Static -> Settings -> Deploy メニューを開き、Deployment Settings で Local Directory を選択します（選択肢にAWS S3もありますが、プラグインの有料版が必要です）。このデプロイ方法は、ローカルファイルシステムに生成された静的サイトを保存します。

PATH で、静的サイトを保存するローカルのディレクトリを指定します。このディレクトリは、Webサーバー（www-data ユーザーなど）が書き込めるパーミッションが必要です。

本記事では、WordPressのルートディレクトリ（/var/www/html）に public_static というディレクトリを作成する例を示します。

cd /var/www/html
mkdir public_static
chown www-data:www-data
chmod 755 public_static

Simply Static -> Diagnostics を選択します。すべての設定にチェックマークが付いており、問題がないことを確認します。もしファイルパーミッションなどで問題がある場合はエラーが表示されますので、修正します。

Simply Static -> Generate ボタンを押すと、静的サイト生成が始まります。進行状況は Activity Log ページで確認できます。

生成が完了したら、ブラウザの「ファイルを開く」などで、生成先ディレクトリ（public_static）の index.html を開きます。file:// プロトコルでサイトをナビゲートできるはずです。主なページを確認して問題ないことを確認します。

相対URLで静的サイト生成

ローカルでの確認後、次はCloudFrontでのテスト用に相対URLで生成します。

Simply Static -> Settings -> General メニューで、Replacing URLs を Offline Usage から Relative Path（相対URL） に変更します。

Relative Path に設定する目的は、後ほど作成するCloudFrontのデフォルトドメイン (distribution_id.cloudfront.net) でアクセスしてもサイトのナビゲーションテストを行えるようにするためです。

Generate ボタンをクリックし、静的サイトを再度生成します。

S3へのアップロード

静的サイトの生成が完了したら、格納ディレクトリ（public_static）に入っている全てのファイルとフォルダを、先ほど作成したS3バケットにアップロードします。

AWS CLIを使ったアップロード

ファイル数が多い場合、AWSマネジメントコンソールからの手動アップロードは大変です。AWS CLI (コマンドラインインターフェース) が使える環境であれば、sync コマンドを使うと差分だけを高速にアップロードできて非常に便利です。

# public_static ディレクトリの中身を、S3バケットのルートに同期（アップロード）する
aws s3 sync ~/wordpress/public_static/ s3://example.com/ --delete

（--delete オプションは、ローカルにないファイルをS3からも削除します。必要に応じて調整してください）

CloudFrontディストリビューション作成

AWS CloudFrontを利用すると、S3バケットに非公開で格納した静的サイトを、独自のドメインとHTTPSを使って高速に配信できます。

CloudFrontディストリビューションを以下の設定で作成します。

Distribution name: ドメイン名など任意の名前
Distribution type: Single website or app
Origin type: Amazon S3
S3 Origin: 作成したS3バケットをBrowse S3で選択
Allow private S3 bucket access to CloudFront: オン。これにより、S3オブジェクトの読み取り権限をCloundFrontのディストリビューションに許可するS3バケットポリシーが自動で付与されると同時に、CloudFrontディストリビューションからS3バケットへのリクエストに署名が付与されるようになります（オリジンアクセスコントロール（OAC）と呼ばれる仕組みです）。
オリジン設定：use recommended settings
Cache settings: use recommended settings
Web Application Firewall: セキュリティ保護を有効にしないでください

ディストリビューションを作成するとデプロイが始まりますので、「一般」タブの「最終変更日時」が更新されるまで待ちます（数分～数十分かかることがあります）。

デプロイが完了したら、「ディストリビューションドメイン名」（your_subdomain.cloudfront.netのような形式）をコピーし、ブラウザでアクセスできるか確認します。

（注） この時点では https://your_subdomain.cloudfront.net/index.html のように、ファイル名を指定しないとアクセスできません。

URLリライト用CloudFront関数の追加

index.html を省略し、サイトルート（/）や記事サブディレクトリ（/your_post_slug/）でアクセスできるよう、URL書き換え関数を作成します。

CloudFrontの左メニューより関数を選択し、関数を作成 をクリックします。

名前：任意の名前を入力（例：index-rewriteなど）
Runtime: cloundfront-js-2.0

以下の関数コードを記載します。

function handler(event) {
    var request = event.request;
    var uri = request.uri;

    // URIがスラッシュで終わっている場合 (例: / や /subdir/)
    // S3オリジンに送る前に末尾に index.html を追加して書き換える
    if (uri.endsWith('/')) {
        request.uri += 'index.html';
    } 
    // URIがファイル拡張子を持たない場合 (例: /subdir)
    // S3オリジンに送る前に /index.html を追加して書き換える
    else if (!uri.includes('.')) {
        request.uri += '/index.html';
    }

    return request;
}

変更を保存 し、発行タブから 関数を発行 します。

同じく発行タブの 関連付けられているディストリビューション セクションから 関連付けを追加 ボタンをクリックします。

ディストリビューション: 先ほど作成したCloudFrontディストリビューションを選択
イベントタイプ：Viewer request
キャッシュビヘイビア：Default(*)

関連付けがデプロイされたら、ブラウザでCloudFrontのディストリビューションドメイン名にアクセスし（例：https://your_subdomain.cloudfront.net/）、index.html なしでサイトが表示されたら成功です。

ドメイン設定 (Route 53, ACM)

AWS Route 53でホストゾーン作成

AWS Route 53で、使用する独自ドメインのホストゾーンを作成します。

ドメイン名: 自身のドメイン (例: example.com)
タイプ: パブリックホストゾーン

AWS Certificate ManagerでTLS証明書作成

CloudFrontで独自ドメインをHTTPS化するため、ACMで無料のTLS証明書を発行します。

Certificate Manager (ACM) のコンソールを開き、バージニア北部 (us-east-1) リージョンを選択します。(CloudFrontで使用する証明書は、必ずこのリージョンで取得する必要があります)

以下の設定で証明書をリクエストします。

証明書タイプ：パブリック証明書をリクエスト
完全修飾ドメイン名：サイトで使用するドメイン名 (例: example.com)
この証明書に別の名前を追加：www.example.com のように、www付きのドメインも追加しておくことを強く推奨します。
エクスポートを許可：エクスポートを無効にする
検証方法：DNS検証
キーアルゴリズム：RSA 2048

証明書リクエストを作成したら、検証画面で Route 53でレコードを作成 ボタンを押します。これにより、ドメインの所有権を検証するためのCNAMEレコードがRoute 53のホストゾーンに自動で追加されます。

（もし、まだネームサーバーをRoute 53に移行しておらず、別のDNSプロバイダーでドメインを管理している場合は、表示されるCNAME名とCNAME値をコピーし、現在のDNSプロバイダー側でCNAMEレコードを作成してください。但しこの検証用CNAMEレコードはTLS証明書発行時のみならず更新時にも必要ですので、いずれにしてもRoute 53には追加する必要があります。）

しばらく待ち、証明書のステータスが「発行済み」になったことを確認します。

CloudFrontとドメインの関連付け・テスト

CloudFrontディストリビューションの管理画面に戻り、一般タブの設定から Add domain をクリックします。

Domains to serveにドメイン名 (例: example.com) を入力します。（wwwあり・なし両方設定する場合は、メインで使う方のみをここで入力します。もう一方はリダイレクト用に後で設定します）

先ほど発行された証明書をAvailable certificatesの項目で選択し、関連付けして保存します。

ディストリビューションの代替ドメイン名の項目にドメイン名が表示され、カスタムSSL証明書にもチェックマークが付きます。

同じセクションでRoute domains to CloudFrontをクリックしてAレコードとAAAAレコードをRoute 53に追加します。

【オプション】ネームサーバー変更前の動作確認

ネームサーバーを切り替える前に、独自ドメインでAWS上のサイトにアクセスできるかテストするには、PCの hosts ファイルを編集します。

CloudFrontディストリビューションのIPアドレスを確認します。（ping your_distribution_id.cloudfront.net 等で調べられますが、IPは変動する可能性があります）

PCの hosts ファイル（Mac/Linux: /etc/hosts, Windows: C:\Windows\System32\drivers\etc\hosts）に、以下の行を追加します。

# /etc/hosts
(調べたIPアドレス) your_domain.com

Chromeのデベロッパーツール（ネットワークタブ）などでレスポンスヘッダーを確認し、Server: AmazonS3, Via: ...CloudFront... となっていれば、AWSに接続されています。

テストが終わったら、hosts ファイルに追加した行は必ず削除（またはコメントアウト）してください。

本番公開と仕上げ

ネームサーバーをRoute 53に変更

独自ドメインを取得したレジストラ（お名前.com、ムームードメインなど）の管理画面で、ネームサーバーの設定を、AWS Route 53のホストゾーンに表示されている4つのNSレコードの値に変更します。

注）ネームサーバーの変更がインターネット全体に反映されるまでには、数時間～最大72時間程度かかる場合があります。変更が反映されるまでの間、万が一トラブルがあってもすぐに切り戻せるよう、Route 53のホストゾーン詳細でNSレコードの TTL を一時的に短い値（例：300秒 = 5分）に変更しておくことも推奨されます。

XMLサイトマップ作成

検索エンジンにサイト構造を伝えるため、XMLサイトマップを作成します。「XML Sitemap Generator for Google」プラグインがおすすめです。

注）もしJetpackプラグインなどでサイトマップを生成していた場合、競合する可能性があるため、古いプラグインのサイトマップ機能は無効化します。

有効化すると http://(ローカルのWordPress URL)/sitemap.xml にサイトマップが作成されます。

Simply Static -> Settings -> General メニューを開き、Additional URLs に、サイトマップのURL（例：sitemap.xml, post-sitemap.xml など、プラグインが生成する全ての子サイトマップのパス）を登録します。

注）Simply StaticのRewrite URLsでRelative Pathを設定していると、サイトマップにも相対URLで記載されてしまいますが、サイトマップは絶対URLで記載する必要があります。これは、後ほど絶対URLを設定する際に解消します。

robots.txt作成

WordPressのルートディレクトリ（index.php などがある場所）に robots.txt という名前のファイルを作成します。Simply Staticは静的サイト生成時にこのファイルを含めてくれます。

User-agent: *
Allow: /

Sitemap: https://your_domain.com/sitemap.xml

絶対URLで静的サイトを更新

本番サイトの動作確認が完了したら、SEO（検索エンジン最適化）のため、全てのリンクを相対URLから絶対URLに更新します。

Simply Static -> Settings -> General メニューより、REPLACING URLS を Absolute URLs に変更します。

SCHEME を https:// に、HOST を自身のドメイン（例：example.com）に変更して設定を保存します。

Generate ボタンで静的サイトを再生成します。この際、XMLサイトマップなども絶対URLで更新されます。

生成が完了したら、再度S3バケットへアップロード（aws s3 sync など）します。

S3のファイルが更新されても、CloudFrontには古いキャッシュが残っている場合があります。CloudFrontの管理画面で キャッシュ削除 (Invalidation) を作成し、/* （すべてのファイル）のキャッシュをクリアしてください。

ルートドメインとwwwのリダイレクト設定

サイトをルートドメイン (example.com) でホスティングしている場合、www.example.com へのアクセスをリダイレクトさせる（またはその逆）設定を行います。ここでは、リダイレクト専用のS3バケットと、もう一つのCloudFrontディストリビューション を使う方法を紹介します。

リダイレクト元S3バケット作成

リダイレクト元S3バケットを、以下の設定で作成します。

バケットタイプ：汎用
バケット名：リダイレクト元のドメイン名（例: www.example.com）。
オブジェクト所有者：ACL 無効
このバケットのブロックパブリックアクセス設定：パブリックアクセスをすべてブロックをオフ（パブリックアクセスを有効化）
バケットのバージョニング：無効にする
暗号化タイプ：Amazon S3 マネージドキーを使用したサーバー側の暗号化 (SSE-S3)
オブジェクトロック：無効にする

S3バケットを作成後、アクセス許可タブを選択して以下のバケットポリシーを設定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.example.com/*"
        }
    ]
}

（Resource のバケット名はご自身のものに置き換えてください）

プロパティタブで、静的ウェブサイトホスティング設定を以下の通りにします。

静的ウェブサイトホスティング：有効にする
ホスティングタイプ：オブジェクトのリクエストをリダイレクトする
ホスト名：リダイレクト先のホスト名（例：example.com）
プロトコル：https

保存すると表示される バケットウェブサイトエンドポイント (例: www.example.com.s3-website-....amazonaws.com) をコピーしておきます。

リダイレクト用CloudFrontディストリビューション作成

次にCloudFrontディストリビューションを以下の設定で作成します。

Distribution name: リダイレクト元ドメイン名など任意の名前
Distribution type: Single website or app
Origin type: Amazon S3
S3 Origin: S3バケット一覧には表示されません。先ほどコピーした S3のバケットウェブサイトエンドポイント を貼り付けます。（http:// は削除してください）
オリジン設定：use recommended settings
Cache settings: use recommended settings
Web Application Firewall: セキュリティ保護を有効にしないでください

ディストリビューションが作成されたら、一般タブより代替ドメイン名でAdd domainボタンを押し、リダイレクト元のドメイン名（例: www.example.com）を入力し、TLS証明書を選択します。TLS証明書は作成の際にルートドメインとwwwドメインを両方とも登録したため、このディストリビューションでも同じ証明書を使います。

代替ドメイン名にドメイン名を追加したら、Route domains to CloudFrontボタンでRoute 53にAレコードとAAAAレコードを追加します。

これで、ブラウザで www.example.com にアクセスすると、https://example.com へリダイレクトされるようになります。

まとめ

本記事では、ローカル環境のWordPressサイトを静的ウェブサイトに変換し、AWS（S3, CloudFront, Route 53）でホスティングする方法を紹介しました。

設定には若干の手間がかかりますが、一度設定を終えれば、WordPressのメリット（簡単な記事作成）と静的ウェブサイトのメリット（高速、セキュリティ対策不要、安価）両方を享受することができます。ぜひ試してみてはいかがでしょうか。

エンジニア術