WordPress移行サイトのカテゴリとナビゲーションを作り直した一日

移行済みの記事は、もう200本を超えていた。本数だけ見れば移行はかなり進んでいたはずだった。ところがカテゴリページを開くと、記事は日付順にただ積まれているだけで、ひとまとまりの目次には見えなかった。

まず状況を掴むために、Sonnet 5のサブエージェントを3本並列で走らせた。自分が普段使っているブログの目次の作り方、移行先の現状、旧WordPressサイトの本番構造をそれぞれ別のエージェントに調べさせ、3本が出揃ったところで差分を見比べる段取りにした。

たとえば簿記の学習記事のカテゴリを開くと、旧サイトでは30本近い記事がひとまとまりの目次として並んでいる。移行先の同じカテゴリを開くと、同じ記事のはずなのに、粗い分類の中に埋もれて一覧性を失っていた。並べて見た瞬間、「イメージが違う」と口に出していた。

WordPressのカテゴリDBから機械的に再構築した、が

最初にやらせたのは、WordPress側のカテゴリDBに残っている分類データをそのまま引き継ぐ方法だった。テーブルにある情報を読み込んで組み直せば、手間もかからず早い。実際、数十分で新しいカテゴリページが仕上がって出てきた。

これで十分だと思っていた。ところが本番サイトを並べて見せられると、そうではなかった。本番の目次には、機械的な分類とは別の何かが乗っていた。記事を難易度の三段階で束ね、そこに切り口の違う複数のトピックをぶら下げる。手作業で編まれた構造だった。WordPressのタクソノミーには、この三段階の枠組みも、トピックとの対応関係もどこにも記録されていない。トップページのHTMLの中にしか存在しない、編集者の頭の中にだけあった情報だった。

データ駆動でできる方法を選んだ結果、本番でいちばん価値のあった編集構造を回収し損ねていた。本番トップの実際の構造をあらためて洗い出させ、三段階の枠組みとトピックの対応関係を作り直すところからやり直した。

縦に積むだけで、長いタイトルは収まった

トップページのトピック一覧は、最初は横に3列で並べていた。並べてみると、タイトルが長い記事のところだけ文字が折り返し、列ごとに高さがバラバラになる。

答えは単純だった。横に3つ並べるのをやめて、縦に積めばいい。1トピックを全幅で使えば、タイトルが多少長くても1行に収まる。考えてみれば、なぜ最初から横3列にこだわっていたのか自分でも説明がつかなかった。縦積みに直させ、生成し直して確認すると、折り返しは消えていた。

サブカテゴリは、機械にやらせず判断させた

トピックの中には、20本近い記事がまとまって入っているものもあった。この中身をどう割るかは、機械的な分類には向いていない。記事タイトルを読んで、内容ベースでサブカテゴリを判断してほしいと伝えた。

9トピック・28記事のタイトルを読ませ、サブカテゴリの区切りを判断させた。たとえば「10倍早く合格するための基礎知識」のような記事は、同じトピックの中でも入門者向けの導入として独立させる、といった具合に、機械的な五十音順やタグの有無ではなく内容の役割で切り分けさせた。分類漏れがないかは数字で確認できる。「その他」に落ちた記事がゼロ件であることを確かめてから、25個のサブグループとして反映させた。

ヘッダーに8項目、ロゴは本番から持ってきた

ホーム・著書・サービス・全記事・コンセプト・プロフィール・お問い合わせ・ブログ。本番サイトのヘッダーにあった8つの項目を、そのままクリック可能なナビとして実装させた。

ロゴは新しく作らず、本番サイトに使われている画像をそのまま持ってこさせた。静止画とアニメーション版、favicon まで回収させ、ヘッダーに組み込んだ。見た目は本番と同じ色合いのナビになった。ナビの下にぶら下がるコンテンツも、本番のリンク構造をそのまま辿らせて確認させた。パートごとの目次リンクが一つでもずれていれば、押した先が違う記事に飛んでしまう。

「著書」は、本のページではなくホームに置くものだった

本のリンクの話には、前段があった。旧サイトより前に作っていた別バージョンには書籍への導線があったのに、今動いている方に寄せてからは、その導線がどこにも残っていないことに気づいた。マネタイズに関わる話なので、気づいたまま放置するわけにはいかない。どこに置き直すかを考えるところから、著書ページ作りが始まった。

著書の項目には、最初、専用ページを作らせて書影とカリキュラムを置かせた。できあがったものを見て、違うと思った。書籍紹介を置きたかったのは、著書の専用ページではなくホームページの方だった。

作りかけの専用ページと書影は消させ、書籍紹介(書影・紹介文・カリキュラムの目次・購入リンク)はホームページの下部に据え直した。「著書」のナビ項目自体は、著者ページへの直接リンクに変えた。ホームに置くか専用ページに置くかで、同じ素材でも意味が変わることを思い知らされた。

サービスの導線と、思わぬ発見

「サービス」の項目は、まず自分が別に運営している仕訳クイズのページに飛ぶようにした。そのクイズ側にも手を入れたい要望があり、勘定科目から選んで出題するタブを追加できるか調べさせた。答えは軽い加工で済む、というものだった。各問題の選択肢データにはもともと勘定科目の情報が構造化されて入っており、全科目の対応表もすでに実装済みだったからだ。

もう一つ、旧サイトに残っていた古い問題集ページの正体も分かった。てっきりWordPressの記事だと思っていたが、調べる途中で「あのページはWordPressの記事じゃなくて、includeを使ったHTMLかPHPのファイルで直接作っていた気がする」という記憶がふと戻ってきた。その勘を調査エージェントに伝えて掘らせると、その通りだった。実際はWordPressの固定ページの器を借りて動く、自己完結型のHTML/JSアプリだった。中には外部APIに依存していて、今は本番でも問題文が表示されなくなっているものもある。ただし調べさせると、そこにあった190問前後の設問データは、すでに新しい方のクイズ機能に移行済みだと分かった。壊れて見えるページの裏で、データそのものは先に救出されていた。

プレビューへは何度も出したが、本番はまだ

カテゴリを作り直すたびに、レイアウトを変えるたびに、生成してCloudflare Pagesのプレビュー環境にデプロイし、その場で画面を確認する。この日は同じサイクルを4回近く回した。確認する項目も毎回同じにした。目次のスクロール追従は効いているか、モバイル幅で崩れていないか、記事一覧やカテゴリページの件数が重複や漏れなく数え合うか。数だけは目で見ても間違えるので、生成ログの件数を突き合わせてから次の作業に進んだ。

「デプロイお願いします」と伝えた場面で、一度立ち止まって確認させた。プレビューへの反映はすでに終えていたが、本番ドメインの切替を指しているなら話は別だ。今動いている旧サイトに直接影響する操作なので、意味を明示的に確認してから進めさせたかった。答え合わせをすると、自分が指していたのはプレビュー環境のことだった。

今日の学び

• カテゴリは「データがある方法」で組むと、「手が入っている方」の価値を取りこぼす。本番の目次構造は、タクソノミーのどこにも書かれていない、編集者の頭の中にしかない情報だった
• 横3列は行儀よく見えても、タイトルの長さという現実の前では壊れる。1トピック全幅の縦積みの方が、結果として頑丈だった
• 同じ書籍紹介コンテンツでも、専用ページに置くかホームに置くかで意味が変わる。作る前に「どこに置くか」を1行で確認していれば、作り直しの手間は減らせた
• 見た目が壊れているページの裏で、データはすでに移行済みということもある。「動いていない」と「消えている」は別の話だった
• 本番への切替は、まだ実行していない