wp-cliでWordPressを新規構築した直後に見直す設定チェックリスト

先日、wp-cliだけでWordPressサイトを1つ新規構築しました。ブラウザのインストールウィザードを通らない構築は速くて再現性が高い一方、ウィザードや管理画面経由なら自動で済む設定がいくつも素通りになります。本記事は、その際に実際にハマった項目と、その流れで見直した項目を、構築初日のチェックリストとしてまとめたものです。

1. .htaccessは自動では作られない — パーマリンク設定だけでは全記事404になる

最初にハマったのがこれです。wp rewrite structure '/%postname%/'でパーマリンクを設定し、トップページは表示されるのに、個別記事が全部404。原因は.htaccessがそもそも存在しないことでした。

wp-cliのrewrite flushはWordPress内部のリライトルールを更新しますが、Apacheに書き換えを伝える.htaccessファイル自体は（書き込み可能でも）作ってくれないことがあります。管理画面のパーマリンク設定画面を一度開くと生成される、あのファイルです。wp-cli構築では標準の内容を自分で置きます。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

2. 基本設定の確認 — タイムゾーン・検索エンジン許可・コメント方針

ウィザードを通らない構築で確認しておきたい基本3点です。

wp option get timezone_string   # Asia/Tokyo になっているか
wp option get blog_public       # 1 = 検索エンジンを許可（0のままだと一生インデックスされない）
wp option update default_comment_status closed   # コメントを使わないサイトなら最初に閉じる
wp option update default_ping_status closed

コメント欄は、運用体制がないまま開けておくとスパムの温床になるだけです。使う予定がないなら、記事が増える前に既定を閉じておくと後から全記事を直す手間がありません。

3. 使わない入口と余計なものを消す

新規インストール直後のWordPressには、使わないものがいくつか同梱されています。放置してもすぐ害はありませんが、更新されないまま残ったコードは攻撃面にしかなりません。

wp plugin delete akismet hello
wp theme delete twentytwentyfour twentytwentythree twentytwentytwo  # フォールバック用に1つは残す
wp post delete 1 2 --force   # 「Hello world!」とサンプルページ

XML-RPC（スマホアプリや外部連携用の古いAPI）も、使わないなら閉じておきます。実際、構築当日からアクセスログには.envや設定ファイルを探るボットが来ていました。新しいドメインでも見つかるのは一瞬です。

add_filter( 'xmlrpc_enabled', '__return_false' );

4. wp-cronはアクセスが無いと動かない — 新規サイトの落とし穴

WordPressの予約投稿や定期処理（wp-cron）は「誰かがサイトを訪れたとき」に動く仕組みです。つまりアクセスがほぼゼロの新規サイトでは、cronが予定時刻になっても動きません。予約投稿が公開されない・定期処理が走らないという相談の定番原因です。サーバーのcrontabから定期的に叩いて解決します。

*/15 * * * * /usr/bin/curl -s -o /dev/null https://example.jp/wp-cron.php?doing_wp_cron

5. 忘れがちな仕上げ — サイトアイコンとDBバックアップ

サイトアイコン（ファビコン）は後回しにしがちですが、検索結果にも表示されるため、インデックスされる前に設定しておくのが理想です。512×512のPNGを用意して、メディアに上げてからsite_iconに指定します。

ICON=$(wp media import icon-512.png --porcelain)
wp option update site_icon $ICON

バックアップは、プラグインを入れるほどでもない初期なら、cronでDBダンプを回すだけでも保険になります。

#!/bin/bash
# /etc/cron.daily/ に配置。7日分だけ保持する
mysqldump DB名 | gzip > /var/backups/site/db-$(date +%Y%m%d).sql.gz
find /var/backups/site -name "*.sql.gz" -mtime +7 -delete

まとめ — wp-cli構築は「ウィザードが裏でやっていたこと」を自分でやる

振り返ると、ハマった項目（.htaccessとwp-cron）はどちらも「ブラウザからインストールして普通に運用していれば意識せずに済んでいたこと」でした。wp-cliでの構築は速く、手順をそのままスクリプト化できる利点がありますが、.htaccessの生成やタイムゾーンのような暗黙の初期化は自分の仕事になります。このチェックリストが、次にゼロから立ち上げる方の初日を短くできれば幸いです。

カスタマイズに関するお問い合わせはこちら