CMSが出力しない50本を、取りに行きました：10年分の更新を1本も落とさず移した記録
株式会社エル・マジェスタのコーポレートサイトを、WordPressから静的サイトへ作り直した記録です。旧サイトのCMSが外部に出力していなかったお知らせ50本をどう回収したか、旧URL249本を1本も落とさず引き継いだ方法、アラビア語版を用意した理由を、実測値とあわせて公開しています。
この事例について
| 項目 | 内容 |
|---|---|
| 対象 | 株式会社エル・マジェスタ様 コーポレートサイト（el-majesta.com） |
| 業種 | 音楽・エンターテインメント（登録音楽家100名の出張生演奏） |
| 進め方 | 既存WordPressの改修ではなく、静的サイトとしての作り直し |
| 移行した記事 | 124本（旧ブログ74本＋お知らせ50本） |
| 構築したページ | 139ページ（2026年9月時点） |
| 旧URLの引き継ぎ | 249本を検証し、274行のリダイレクトで受け |
| AEOスコア | 3.9 → 8.1（当社の8観点診断・各10点） |
| 公開 | 2026年9月2日（wwwなしを含む完全移行は9月3日） |
なぜ、直さずに作り直したのか
旧サイトはWordPressとBizVektorテーマで構築されており、最後の本格的な更新は2016年でした。10年のあいだにお知らせは積み上がっていましたが、サイトの構造そのものは当時のまま止まっていました。
この状態を部分改修で直そうとすると、テーマの制約に合わせて1ページずつ手を入れることになります。構造化データを1種類足すたびに、テーマのどのテンプレートを触ればよいかを調べ、影響範囲を確認し、更新のたびに壊れないかを見る。ページ数のぶんだけ、これを繰り返します。
AEOで効くのは、テンプレートの設計です。 見出しを問いの形にすること、その直下の1文で答えを言い切ること、会社・人・サービス・記事を1つのグラフとして機械に読ませること。これらはページ単位の修正では揃いません。
だから作り直しました。
何を変えたのか
見た目を新しくすることが目的ではありません。変えたのは、情報の持ち方です。
構造化データを全ページに入れました。 会社（Organization）、サービス（Service）、記事（BlogPosting）、代表者（Person）、パンくず（BreadcrumbList）が相互に参照し合う形になっています。旧サイトの記事ページには、構造化データは1件も入っていませんでした（保存した旧HTML 50本を機械照合・0/50）。
よくある質問を6ページに、23問配置しました。 すべてFAQPageとして機械が読める形にしています。「何名編成を選べばよいか」「依頼から当日までに何が必要か」といった、実際に問い合わせで訊かれる問いをそのまま見出しにしています。
HTTPSに対応しました。 旧サイトは有効なHTTPS配信ができず、画像すらhttpでしか出せない状態でした。新サイトはCloudflare上で証明書を自動発行しています。
存在しないURLが正しく404を返すようにしました。 旧サイトは、どんなURLを叩いてもトップページが200で返る状態でした。検索エンジンから見ると、無数の重複ページがあることになります。
llms.txt を設置しました。 AI検索のクローラーに向けて、サイトの構造と主要ページを明示しています。
英語版とアラビア語版のページを用意しました。
いちばん手間がかかったのは、CMSに出てこない50本でした
移行作業そのものは、スクリプトで機械的に処理できます。判断と手間が要ったのは、お知らせ50本の回収でした。
旧サイトのWordPressには、記事を外部から取り出すための標準的な入り口（REST API）があります。ところが、お知らせだけは独自の投稿タイプで管理されており、この入り口に出てきませんでした。
普通に取得すると、記事は74本しか出てきません。そしてその74本の最新は2025年1月でした。
一方、実際のお知らせの最新は2026年7月です。つまり、取れる分だけで作っていたら、新サイトは公開初日から1年半古い状態になっていたことになります。
そこで、お知らせ50本のページを1本ずつ取得し、本文を抜き出して統合しました。結果、記事は74本から124本になり、サイトの最新更新は2025年1月から2026年7月へ移りました。
情報の鮮度は、AEOの評価観点のひとつです。 更新が止まって見えるサイトは、AIから「現在も活動しているか」を判断されにくくなります。ここは手作業をしてでも取りに行く価値がありました。
副産物として、計測の穴が見つかりました
回収したお知らせ50本を調べたところ、Googleアナリティクスの計測タグが1本も入っていませんでした（0/50・機械照合による）。canonicalタグとOGP画像の指定も、同じく0/50です。
10年ぶんの更新が、計測からもSNSシェアの見え方からも漏れていたことになります。新サイトでは全ページが計測対象です。
このため、公開後にアクセス数が増えて見えることがありますが、実際の増加ではなく、計測できる範囲が広がったためです。前後比較の際は注意が必要だと、事前にお伝えしています。
旧URLは、1本も捨てませんでした
旧サイトのURLは249本ありました。日本語がそのままURLに入った、いわゆる日本語URLも多数含まれています。
これを249本すべて洗い出し、新サイトの対応先へ振り分けました。1対1で移せるものはそのまま、統合したものはまとめ先へ。行き先のないURLはゼロです。
最終的なリダイレクトは274行（静的263・動的11）になりました。公開後は、この249本すべてに実際にアクセスして到達を確認するスクリプトを走らせています。
ここで1つ、危うい設定ミスを見つけています
Cloudflareのリダイレクト設定には、**「ワイルドカードを使った動的なルールは、固定のルールより後ろに書かなければならない」**という仕様があります。
最初の実装では、動的ルールがファイルの途中に混ざっていました。この状態だと、それ以降に書いた約150本の固定ルールが黙って無視されます。エラーは出ません。
社内レビューで指摘を受けて検証したところ発覚し、固定ルールを先、動的ルールを後ろに並べ替える形へ修正しました。公開前に見つかったのは幸運でしたが、「エラーが出ない失敗」は検証しない限り分からないという典型例です。
アラビア語版をつくった理由
中東での公演営業のためです。
単純な翻訳ではなく、右から左に読む言語（RTL）としてレイアウトを反転させています。文字送りの設定も日本語や英語とは変える必要があります（アラビア文字は隣の文字と繋がるため、字間を空けると単語として読めなくなります）。ロゴやメニューの位置、スクロールする実績表示の流れる向きも、すべて左右を入れ替えています。
電話番号などの数字だけは、反転させずに元の並びを保つよう個別に指定しています。
なお、現時点の訳文はAIによる下訳です。公開前にネイティブによる確認が必要である旨は、あわせてお伝えしています。
いま、どうなっているか
当社のAEO診断（8観点・各10点）で、3.9点から8.1点になりました。
| 観点 | 主な変化 |
|---|---|
| 信頼性（E-E-A-T） | 代表者・所在地・設立年・実績を構造化データで明示 |
| 構造化データ | 0件 → 全139ページに設置（16種類） |
| FAQ・Q&A適合 | なし → 6ページ・23問をFAQPageで実装 |
| コンテンツ網羅性 | サービスの選び方・依頼の流れを新規に作成 |
| 事例・実績の可視化 | 取引先・出演メディアを一覧化し機械可読に |
| 情報の鮮度 | 最新更新 2025年1月 → 2026年7月 |
| 技術・クローラビリティ | HTTPS対応・404の正常化・llms.txt設置 |
| エンティティ・指名性 | 会社／サービス／記事／人物を相互参照する構造へ |
出典：株式会社トライエッジ AEO診断（当社基準の内部診断・2026年9月時点）
公開してからのほうが、見つかりました
新しいサイトが表示された時点で終わり、ではありませんでした。公開後に見つけて直したものを、隠さずに書いておきます。
検索結果に出ていたのは、新しいサイトではありませんでした。 Googleが「正しいアドレス」と見なしていたのは www なしの旧アドレスで、そこを開くと旧サイトが表示される状態が残っていました。新サイト自体は動いているのに、検索から来た方には届いていません。旧サーバー側で転送を設定し、www なしで来られた方も新サイトへ渡るようにしました。この時点まで、移行は完了していなかったことになります。
その結果、9月4日にGoogleが新サイトを読み直し、正規のアドレスが新サイトへ切り替わりました。
英語版とアラビア語版が、検索に出ない設定のままでした。 日本語ページは自動生成に載せていたのに、この2ページだけ手書きのまま残っていたためです。公開スイッチを切り替えても、この2枚には効きませんでした。生成の仕組みに寄せ直して解消しています。
作業用フォルダが、そのまま公開されていました。 旧サイトから取得したHTMLを置いていたフォルダが、外から読める状態でした。旧サイトの内容が新ドメイン上にもう一組ある形になり、自分で重複を作っていたことになります。転送とヘッダーの両方で塞ぎました。
SNSに貼っても、写真が出ませんでした。 サムネイル用の画像をWebP形式で指定していたためです。表示速度には有利ですが、SNS側が公式に対応している形式に含まれていませんでした。表示用はWebPのまま、SNS用にJPEGを自動生成して差し替える形にしています。
いずれも画面を見ているだけでは分からない不具合でした。公開後に外側から機械的に確かめて、はじめて出てきています。
この事例から言えること
外から取れるデータだけで移行を組むと、いちばん新しい情報が抜け落ちることがあります。
今回、標準的な方法で取得できたのは74本、そこに含まれる最新は2025年1月でした。取れなかった50本のほうに、2026年の更新が入っていました。移行の前に「これで全部か」を数で確かめる工程がなければ、気づかないまま公開していたはずです。
そしてもう1つ。エラーが出ない失敗は、検証しなければ見つかりません。 リダイレクトの並び順も、計測タグの欠落も、公開後に残っていた4件も、画面を見ているだけでは分かりませんでした。機械的に数えて初めて出てきています。
だから当社は、公開を「納品日」ではなく外側から検証を始める日として扱っています。
同じ進め方を Webサイト構築（AEO対応） としてご提供しています。金額は料金ページに公開しています。
よくある質問
Q. なぜ既存のWordPressを直さず、作り直したのですか？
AEOで効くのがページ単位の修正ではなく、テンプレートの設計だからです。見出しを問いの形にする、直下の1文で答えを言い切る、会社・人・サービス・記事を1つのグラフとして繋ぐ。この3つはページごとの手直しでは揃いません。旧サイトはテーマの構造が2016年当時のままで、1ページ触るたびにテーマの制約を調べ直す必要がありました。ページ数が多いほど、作り直したほうが早く、費用も下がります。
Q. お知らせ50本は、どうやって回収したのですか？
WordPressの標準的な取得口（REST API）に出てこない投稿タイプだったため、公開されているページを1本ずつ取得し、本文部分を抜き出して統合しました。取得した生のHTMLは手元に保存してあるので、抽出のやり方を間違えても、旧サイトに再度アクセスせずにやり直せる形にしています。実際に1度やり直しています。
Q. 旧サイトのURLは、どうなりましたか？
249本すべてを引き継いでいます。1対1で移せるものはそのまま、統合したページはまとめ先へ301リダイレクトで転送しています。行き先が決まっていないURLはありません。公開後は249本すべてに実際にアクセスし、到達を確認するスクリプトを走らせています。
Q. アラビア語版まで必要だったのですか？
中東での公演営業のためにご要望をいただいたものです。右から左に読む言語のため、翻訳だけでなくレイアウトの左右反転、文字送りの設定、数字部分の並び順の個別指定まで行っています。現時点の訳文はAIによる下訳であり、公開前のネイティブ確認が必要であることは、あわせてお伝えしています。
Q. 公開したあとに、問題は出ませんでしたか？
4件見つけて直しています。wwwなしのアドレスが旧サイトを表示したままだったこと、英語版とアラビア語版が検索に出ない設定で残っていたこと、作業用フォルダが公開されていたこと、SNSに貼っても写真が出ない画像形式だったことです。いずれも画面を見ているだけでは分からない不具合で、公開後に外側から機械的に確認して見つけています。当社は公開日を納品日ではなく、検証を始める日として扱っています。
Q. 公開後、アクセス数はどうなりますか？
増えて見える可能性が高いですが、実際の増加とは限りません。旧サイトのお知らせ50本には計測タグが入っておらず、10年ぶんの更新が計測から漏れていたためです。新サイトでは全ページが計測対象になるため、比較する際は「計測範囲が広がった」ことを織り込む必要があります。この点は先方にも事前にお伝えしています。