WordPressからカスタムサイトへ移るには：適した時期と必要な準備

業務上の必要が明確なときに移行する

現行サイトが事業に必要な仕事を繰り返し妨げるなら、カスタムサイトへの投資が役立つかもしれません。編集者が同じ情報を何か所にも入力している。問い合わせの振り分け規則が複雑になり、保守しづらい。商品一覧が増え、現在のページ構成では扱いきれない。例えばそんな状況です。

その場合、実際の仕事に合わせてコンテンツ、編集画面、システム間の連携を設計できます。編集者はイベントを一度入力すれば、日付がサイト全体に一貫して表示されるかもしれません。担当者は必要な顧客情報が添付された問い合わせを受け取れるかもしれません。あらゆる要件を既存のプラグインに合わせる代わりに、次に大切な変更を決められます。

こうした改善には設計、開発、テストが必要です。WordPressを置き換えるだけでは実現しません。計画の甘いカスタムシステムでは、編集機能が減り、保守費用が増えるおそれがあります。

まず事業の言葉で問題を説明します。誰が何に困り、どのくらいの頻度で起こり、時間や失った仕事としてどんな負担があり、満足できる結果は何か。そのうえで実現方法を比較します。要件を満たし、誰かが運用を続けられる選択肢の中から、負担の最も小さいものを選びましょう。

必要なのはどの種類の変更か

「新しいサイト」という言葉は、かなり違う複数の案件を指します。価格を比べる前に、何を発注するのか明確にしましょう。

サイトの土台が合っていて運用方法だけが問題なら、事業者の変更で足りる場合があります。サイトを作り直さずに事業者を変えるためのガイドでは、その判断を別に説明しています。

ヘッドレスWordPressも実際の選択肢です。WordPress REST APIを使うと、アクセス権限の範囲で別のアプリがコンテンツを扱えます。ただし全プラグインのデータや動作がそのAPIから利用できるわけではありません。新しい表示側が古いコンテンツ構造やプラグインの規則に依存することもあります。何を解決するか、WordPressに何を残すか、連携を誰が保守するか確認してください。

WordPressを使い続ける方がよいとき

チームが無理なく公開でき、必要な機能が動き、変更も比較的容易なら、そのまま使うのが合理的かもしれません。通常の公開業務だけでは、置き換えを発注する理由にはなりません。

扱いにくいサイトでも、修理できる問題かもしれません。ページが遅いなら画像、ホスティング、データベースの処理、特定機能を調べる必要があります。編集画面の使いにくさは、コンテンツ構造を整理したりWordPress側を改善したりして解決する場合があります。プラグインの数だけで判断せず、問題とその影響を数えましょう。

適した標準的なサービスも比較してください。予約、通販、公開の必要をすでに満たすものがあれば、設定して慎重に移す方が、専用システムより運用の手間が少ないかもしれません。

自社の対応力も関係します。誰かがカスタムシステムの要件を決め、実現したか確認し、運用費を負担する必要があります。技術面の運用は外部に頼めますが、事業側にも判断して成果物を受け入れる人が要ります。その余力がないなら、管理しやすい既存サービスの方が合うことがあります。

サイトが実際にしている仕事を調べる

ページ数は出発点です。移行範囲を決めるのは、その背後のコンテンツ、関係、仕事です。

サイトを使い運営する人と一緒に確認します。訪問者には見えない部分も含めてください。

• コンテンツ：ページ、記事、ほかの種類のコンテンツ、カテゴリーとタグ、著者と公開日、翻訳とそれぞれの関係。
• メディア：元の画像やファイル、キャプション、代替テキスト、添付ファイル、各素材の使用先。
• 探し方：メニュー、検索、絞り込み、URLの形式、既存のリダイレクト、SEOタイトルと説明、検索エンジンに登録させるページの規則。
• 訪問者の操作：フォーム、確認表示、メール送信、ログイン、アカウントへのアクセスと権限。
• 連携する仕事：顧客管理や会計システム、メール配信ツール、分析、データの入出力、定期処理などの裏側の仕事。

各項目について、残す、置き換える、廃止するのどれかを決めます。誰が決定し、結果が動くことをどう確認するか記録します。使われていないプラグインは消せるかもしれませんが、別のプラグインは営業チームが頼る問い合わせをひそかに送っているかもしれません。

商品、会員、予約を扱うなら、その仕事は別に範囲を定めてください。商品、注文、顧客のアクセス権、更新、空き状況、連携する事業者には個別の判断が必要です。コンテンツの移行だけでは、継続中のサブスクリプションや既存予約をどう引き継ぐかは決まりません。移行可能だと約束する前に、実際のシステムと提供会社を調べる必要があります。

公開ページと同じくらい編集画面を大切に設計する

WordPressを離れても管理画面を持つことはできます。チームがそこで何をできるべきか指定しましょう。カスタム開発には、編集者が使い慣れた機能が自動的にすべて含まれるわけではありません。

コンテンツの種類ごとに必要な項目を決めます。イベントなら日付、会場、予約リンク、関連記事などです。それぞれを独立した入力欄にすると再利用や検証がしやすくなります。同時に、数日続くイベント、未定の会場、後から追加する予約リンクのような例外も決める必要があります。

作成、承認、公開を誰ができるかも合意します。必要に応じて下書き、公開予約、プレビュー、変更履歴、メディア、メニュー、検索、リダイレクトの編集を含めます。編集者が間違いをどう直し、変更を取り消せるかも決めます。

編集画面を受け入れる前に、実際の利用者に代表的な仕事をしてもらってください。記事を用意し、画像と代替テキストを追加し、スマートフォンで確認し、公開を予約し、誤りを直し、古い記事を探します。助けが必要な場所を観察しましょう。見栄えのよい実演より、自社の人が日常業務を終えられるかの方が役立ちます。

何を移せて、何を作り直す必要があるか

WordPressにはエクスポート機能があります。WXR形式のエクスポートには、投稿、ページ、独自のコンテンツ種別、コメント、フィールド、カテゴリー、タグなど、文書化されたデータが含まれます。移行元として有用ですが、サイト全体が動く状態の複製ではありません。

移行チームは、実際のサイトに何が保存されているか調べます。データベース、アップロードファイル、エクスポート、APIの応答、プラグイン固有の記録です。変換前に安全な元データを残してください。必要な項目の保存先と記録同士の関係を見つけます。

対応付けとは、古い値を新システムのどこに置くか決めることです。著者は正しい記事に結び付き、カテゴリーは新しい「トピック」になるかもしれません。関連記事へのリンクは、その記事の新しいページを指す必要があります。欠けた値や重複は、黙って捨てずに処理方法を合意します。

画像は別に移して確認します。新しい場所にファイルがあり、正しいコンテンツに結び付き、適切な大きさで読み込めるかを確かめます。必要なら埋め込み画像やダウンロードのURLも直します。移行後のページに画像が見えても、閉じる予定の旧サイトから配信されているなら十分ではありません。

コンテンツのレイアウトも調べます。WordPressによると、ブロックにはマークアップと属性が保存され、動的なブロックには後で生成する表示の代わりに印だけが保存されることがあります。そのためコピーした記事に、新システムが理解できない指示が含まれるかもしれません。ページ作成ツールにも独自の構造があり、別途確認が必要です。

新システムが扱える部品へ変換する、特定のレイアウトを作り直す、編集側の承認を得て古いページを簡素化する、といった解決策があります。見えているHTMLをコピーすれば外観を保てる場合もありますが、その後に編集者が適切に更新できる証明にはなりません。公開時の見た目と編集時の動作の両方を決めましょう。

小さな出版社の例

WordPressサイトを移す出版社を想像してください。これは仮の例で、顧客の成果ではありません。試験用の記事には著者、メイン画像、関連記事二つ、広告についての問い合わせフォームがあります。

記事のタイトルと本文は正しく取り込めました。次に著者と公開日が残り、関連記事が正しいページへ移り、画像がキャプションと代替テキストと一緒に移ったかを確認します。編集者が記事を開き、導入を変えて結果をプレビューします。コンテンツと編集方法を一緒に試すわけです。

フォームは別の仕事です。代わりのフォームは合意した情報を集め、目的の場所に保存または送信し、訪問者にわかりやすい確認を返す必要があります。担当者が試しに送信し、実際に届いたか確認します。旧ページにフォームがあっても、その動作が記事と一緒に移るわけではありません。

これで出版社には、記事、画像、編集者の仕事、訪問者の問い合わせという四点の証拠ができました。サイトのさまざまな構造で同じ確認を繰り返せば、「投稿をインポートできる」という説明より、範囲を決める根拠になります。

役立つURLを残し、変更を計画する

コンテンツシステムを置き換えても、ドメインや既存のページパスは多くの場合残せます。使えるアドレスを残したいなら、明確に求めてください。CMSの変更に新しいドメインやURL形式は必須ではありません。

アドレスを変える必要がある場合は、旧ページを適切な新ページに対応付け、転送を試します。すべてをトップページへ送らないでください。廃止した記事、まとめた話題、移した商品は、訪問者が探していたものに応じて判断します。

URL変更を伴う移行に関するGoogleのガイドは、URLの対応付け、恒久的なリダイレクト、正規URL、内部リンク、画像、言語別ページの参照、サイトマップの確認を扱います。正規URLは、どの版のページを優先するか検索エンジンに示します。テストサイトや古いアドレスではなく、公開中の新しいページを指すようにしてください。

タイトルと説明、検索登録の規則、言語別ルート、コンテンツ内のリンクも確認します。公開時にはテスト環境の制限を正しく扱います。必要に応じてテストサイトは非公開に保ち、公開予定のページはアクセスできて検索エンジンに登録可能な状態にします。

Googleのアドレス変更ツールは、ドメインまたはサブドメインの移転に関するものです。同じアドレスのままWordPressだけを置き換える場合、それだけを理由に使うものではありません。

大きな変更の後は検索順位が変動することがあります。何を監視し、ページが見つからない場合や予想外の流入変化を誰が調べ、どう直すか合意します。移行計画で順位低下ゼロや自動的な成長を約束することはできません。

公開前に何が動くべきか合意する

サイトが果たす仕事に沿って受け入れ検査を作ります。コンテンツ、画像、リンクを比べ、実際の動作も試します。フォームは適切な場所へ送信し、検索は代表的な項目を見つけるべきです。権限のある人はログインでき、ない人は拒否されます。編集者は合意した仕事を終えられる必要があります。

購入、予約、連携が範囲に入るなら、その流れと重要な例外も試します。連携先のシステムが記録を受け取る必要があるなら、画面上の成功表示だけでは結果の一部にすぎません。

この仕事には保護されたテスト環境を使います。個人情報へのアクセスを制限し、テストが実際の顧客にメッセージを送ったり、意図しない本番の処理を起こしたりしないようにします。使えるデータとテスト用コピーの扱いを決めてください。

新サイトの準備中に入る変更も計画します。公開を短期間止めて最後の変更を移す方法も、最初の取り込み後に増えた記録を最後に移す方法もあります。各段階でどちらのシステムが正式な記録を持つか決めます。そうしないと、編集者が片方で記事を直す間に、訪問者がもう片方へ問い合わせるかもしれません。

システムを置き換える間に新旧を並行運用するためのガイドでは、責任の所在と移行時の判断を詳しく扱っています。

現実的な切り戻しも決めます。WordPressのバックアップのガイドは復旧に必要なデータベースとファイルを区別します。コピーがあるのは出発点で、必要なサービスを復旧できる証拠は別に要ります。サイトのバックアップで何を復旧すべきかの記事で確認点を説明しています。

新サイトが問い合わせ、注文、編集を受けたり別のサービスへ指示を送ったりした後は、旧サイトへの切り戻しが複雑になります。その記録と操作を照合する必要があります。昨日のデータベースを戻せば今日の事業も保てるとは限りません。公開前に切り戻しの条件と責任者を決めます。

費用と期間を決めるもの

コンテンツの量は大切ですが、種類の違いも同じくらい効きます。統一された構造の数千記事の方が、個別に作られ特別な動作を持つ少数のページより、作業量を見積もりやすいかもしれません。

比べられる見積もりには、仕事の前提を説明してもらいましょう。

• どのコンテンツ構造、独自ブロック、プラグインの記録を調べ、変換するのか。
• どの連携、アカウント、取引、言語を含めるのか。
• デザイン変更とコンテンツ整理をどの程度行うのか。
• どの編集機能、権限、研修が必要か。
• どのテスト、公開時の対応、継続運用の備え、公開後の仕事を含めるのか。

自社チームの時間も見込みます。担当者がアクセスを渡し、質問に答え、廃止するものを決め、コンテンツを整理し、編集画面を試して成果物を受け入れる必要があります。意思決定者が不在なら、開発の準備ができていても仕事は止まります。

提供会社には、決まっている仕事と調査が必要な項目を分けてもらいます。難しいページやプラグイン依存の機能を試しに変換すれば、全体を発注する前に高額な不確実性を減らせます。中身を調べていないエクスポートから固定価格を出すと、提供会社ごとの前提の違いが隠れます。

構築費だけでなく、それぞれの運用費も比べます。ホスティング、ライセンス、外部サービス、更新、バックアップ、監視、サポート、後の変更を含めます。WordPressを残しても費用はかかり、専用ソフトウェアにも費用はかかります。使う予定の期間に各案が何を提供し、誰が責任を持つかを明確にして比較します。

専用システムを誰が維持するか

これは案を選ぶときに合意します。カスタムサイトもフレームワーク、ライブラリ、ホスティング、連携サービスに依存し、手入れが必要です。セキュリティも継続的な仕事です。WordPressのセキュリティガイドはリスクの低減と責任分担を説明しています。プラットフォームを変えても、担当を決める必要はなくなりません。

更新、バックアップ、監視、障害時の支援を契約に入れます。誰が通知を受け、誰が対応でき、緊急の問題をどう報告し、実際にどこまで支援するか明記します。不具合だけでなく、通常の改善を進める方法も用意します。

アクセスと引き継ぎも明確にします。ホスティングと公開作業のアカウント、認証情報、データの書き出し、文書、ライセンス、該当する場合のリポジトリやソースへのアクセスです。ソースを見られるだけで著作権が移るわけではなく、別の提供会社が運用できるとも限りません。役立つ引き継ぎには、公開、復旧、依存するサービスの扱い方も含まれます。

GoogleのAcacio CruzとAshish Bhambhaniは、サービス運用の準備に関する記事で文書、研修、運用責任の移管を説明しています。小規模企業にGoogleの組織構造は要りません。責任を担う人に仕事の知識とアクセス権が必要、という点は同じです。

LINK-Vはサイトとカスタムシステム、移行、連携、デザイン、継続的な保守を提供します。構築、権利、引き継ぎ、その後のケアは案件ごとに合意します。必要な仕事に応じてカスタム開発または個別のサービスをご相談いただけます。

最初の相談に用意するもの

技術仕様書を持ってくる必要はありません。問題が見えるよう、次の情報を用意してください。

• 現在のサイトと、その管理画面、ホスティング、ドメイン、連携サービスへのアクセスを誰が持つか。
• 繰り返す困りごとと具体例、代わりに実現したい仕事。
• 残すべきコンテンツ、機能、役立つURLと、廃止したいもの。
• 新サイトのテストに参加する編集者や他の利用者。
• 連携サービス、重要な取引日や公開日、事業が許容できる停止時間。
• 費用、権利、アクセス、支援、将来の変更に関する質問。

これで次の相談の目的が具体的になります。現行サイトの改善で足りるかを判断し、不明点を見つけ、置き換えを発注する前に何を証明すべきか合意できます。