第4回：土台は1日で完成した——ここからは、LLMに読まれる設計へ
「やっとここまで辿り着いた。朝は白画面、夜にはLLMのSEOを実施する土台が完成した。」
同じ一日の中で、私は何度も同じURLを開きなおした。
午前中は“HTTP 500”や“重大なエラー”が真っ白に出迎え、昼は return の置き場所で転び、夕方はデータベースの扉に“Access denied”と叱られた。
でも夜、フロントも管理画面も静かに立ち上がった。
PHP 8.3、MySQL 8.0、テーマの互換修正、ログ設定の見直し、キャッシュの整備。
全部“今日”やった。長い一日だったけれど、ここからが本題だ。
私「サイトヘルスは“良好”になった。ここから本当にLLM-SEO？」
AI「うん。土台は完成。次は“AIが要約しやすい記事の作り”だね。」
これまでのハイライト
- 朝：PHPを8.3へ。白画面。
→ ログの出し方を覚える。テーマの古い書き方（コンストラクタ、endif; の欠落、reCAPTCHAの処理）を直す。 - 昼：DBを5.6→8.0へ。
→ “DB選択忘れ”や CREATE DATABASE の不要行で詰まる → 直して通す。wp-config.php を新サーバー情報へ。 - 夕：サイトヘルスの黄色信号（デバッグ表示・キャッシュ）。
→ 表示は切ってログだけ残す。オブジェクトキャッシュ（Docket Cache）もセット。 - 夜：フロントも管理画面も安定。
→ これでやっと、LLMに読まれる“記事”を作る段だ。
私とAIの「骨格設計」メモ
AI「“記事の骨格”は一度決めれば毎回使える。今日は“理由とやり方”を腹落ちするまで丁寧に書くよ。」
1. 冒頭の“要点3〜5行”は、読者とLLMの共通インデックス
- なぜ：LLMは要約を作る。冒頭に“何が分かるか／誰向けか／結論”があると、そのまま回答の芯になる。
- どう書く：
- 1行目：この記事の到達点（例：『PHP8.3とMySQL8.0への移行を、初学者でも安全に完了できる』）
- 2行目：対象読者（例：WordPressで白画面になって困る人）
- 3〜4行目：やる手順の全体像（例：バックアップ→PHP切替→テーマ修正→DB引っ越し→ログ最適化）
- 注意：情緒的な導入はこのあと。冒頭は情報の箱を作る意識。
2. 見出し（H2/H3）は“質問→回答”の形にする
- なぜ：LLMはQ&A構造を理解しやすい。人間も読み進めやすい。
- どう書く：
- H2：質問（例：『WordPressで白画面が出たら、最初に何を見る？』）
- 直下：結論の短文（例：『まずエラーログ。wp-content/debug.log を開き、ファイル名と行番号を確認する。』）
- 続けて：理由→手順→注意点（3〜6行でコンパクトに）
- 注意：見出しに固有名詞や具体語を入れる（“白画面”“debug.log”“functions.php”など）。抽象語だけは避ける。
3. 記事末にFAQ（3〜5問）を常設
- なぜ：LLMは短いQAを抜き出す。FAQは拾われやすい要約素材。
- どう書く：
- Qは初心者が実際に入力しそうな文体で（例：「Parse errorって何？」）。
- Aは一文の結論→具体例の順（例：「PHPの文法エラーです。return の位置や閉じタグの欠落など…」）。
- 注意：FAQは本文の繰り返しでOK。重ねることで“答え”として強くなる。
4. 構造化データ（スキーマ）は素朴に正確に
- なぜ：検索エンジンにもLLMにもメタ情報を渡せる。
- どう書く：
- 記事：Article（headline, datePublished, author, mainEntityOfPage など）。
- FAQ：FAQPage（各Q&Aを acceptedAnswer で）。
- 注意：盛りすぎない。埋められる項目を正確に、ダミーは書かない。
5. 著者と運営の透明性
- なぜ：LLMも“誰が書いたか”“連絡先はあるか”を参照する傾向。信頼の土台。
- どう書く：
- フッターやサイドにAbout/Contactを固定。
- 記事末に更新日と更新理由を1行（例：「2025-10-02：PHP8.3対応手順を追記」）。
- 注意：顔写真や過度な自己PRは不要。連絡手段と責任の所在が見えれば十分。
6. 内部リンクは“学習ルート”として設計
- なぜ：LLMは記事同士の関係も要約する。
- どう貼る：
- 連載なら、各回の冒頭と末尾に前後リンクを明示。
- 本文中にも「先に読むべき1本」だけ強く指差す（リンク多すぎは逆効果）。
- 注意：リンクテキストは具体に（「第2回：白画面の原因をログから読む」）。
7. 速度は“足さない勇気”で守る
- なぜ：LLMは読み切るが、遅いサイトは読者が離れる。
- やること：
- 画像はWebP、幅に合わせてリサイズ（オリジナルをそのまま出さない）。
- プラグインは増やさない。要らなくなったら無効化→削除。
- 注意：新しい“高速化プラグイン”は1つずつ試し、効果が薄ければ戻す。
初心者の自分に向けた、未来の私からのメモ
AI「“今日の私”が明日もう一度やるなら、ここを見る、という覚え書き。」
- 白画面＝想定内。最初に見るのは“ログ”
- 画面の謎メッセージより、wp-content/debug.log のファイル名と行番号が信頼できる。
- 例：「functions.php on line 14」と出たら、その行の前後10行まで読む。return の位置、未閉じのカッコ、endif; の欠落が多い。
- ファイル修正は“戻せる体制”で
- 修正前にリネームで退避（functions.php.bak-yyyy-mm-dd）。
- 失敗しても、FTPかファイルマネージャで即座に差し戻せるようにしておく。
- DB移行は“4点チェック”で必ず終わる
- ①ユーザー/パスワードが新DBに通るか
- ②phpMyAdminで新DBを選択してからインポートしたか
- ③ダンプの先頭にある CREATE DATABASE を消したか（共有環境では不要で失敗の元）
- ④wp-config.php のDB名/ホスト/ユーザー/パスを新情報に変えたか
- ここまでやれば“Access denied”“#1046”は消える。
- ログは“表示OFF・記録ON”がちょうどいい
- 本番でエラーを画面に出さない（セキュリティと体験のため）。
- でもログは残す。静かに起きたエラーの痕跡が後で役立つ。
- “完璧主義”は後回し。致命的から順に
- Parse error や Fatal error を最優先で潰す。
- Deprecated はあとでまとめて。今日は前に進むことが勝ち。
今日の終わりに——ここから“見える改善”へ
私「やっと、記事そのものに向き合える。LLMに要約されやすい文章を書ける。」
AI「うん。次は実際の1本を一緒に作ろう。冒頭サマリー、質問見出し、FAQ、スキーマ、内部リンクの流れで。」
ここまでで、私はホームページが壊れた理由と直し方を覚えた。
そして今日、壊れない土台ができた。
ここからは読者に伝わる文章でありながら、LLMに拾われるコンテンツを積み上げていく段階だ。
私「初心者でもできる？」
AI「できる。戻せる工夫と小さく進める癖があれば、ちゃんと進む。次は“LLMに読まれる記事”を一緒に書こう。」
ということで、ホームページの改修編は、ここで終了。
何とか無事に回収を終えて、LLMに読まれるホームページの土台が整いました。
次はいよいよLLMに最適化したホームページにするための施策を実行していきます。