今のWordPressサイトをSWELLに変えようと考えたとき、まず気になるのは、新しい見た目と、移行にどれくらい手間がかかるかだと思います。記事が多いサイトだと、トップページを整えるより、過去の記事に残っている装飾や設定を調べるほうが大きな作業になることもあります。
テーマを切り替えたあとも、記事が問題なく読めるか、問い合わせが届くか、SEOの設定が引き継がれているかは確かめなければなりません。今のサイトで使っている機能を先に洗い出し、検証環境で試してから本番を切り替える。この順番で進めれば、公開後に慌てて直す箇所を減らせます。
今のテーマでしか使えない機能を調べる
WordPressの記事本文には、普通の文章のほかに、テーマ独自のショートコードやブロック、装飾用の指定が入っていることがあります。こうしたものは旧テーマが処理していたので、テーマを変えると同じようには表示されない場合があります。
たとえば、旧テーマの機能で作った料金の囲み枠やボタン、ランキング表示があったとします。テーマを変えたあと、文字だけが残るのか、ショートコードがそのまま見えてしまうのか、中身ごと表示されなくなるのかは、作り方によって違います。ページ数だけで移行の手間を見積もるのではなく、どんな装飾や機能を使っているかを先に調べておきます。
| 調べる場所 | 確認する内容 | 移行時に決めること |
|---|---|---|
| 本文 | 独自ブロック、ショートコード、装飾クラス | 置き換える表現と対象記事 |
| ヘッダー・フッター | メニュー、連絡先、共通の案内 | SWELLで再設定する情報 |
| 子テーマ・追加コード | 独自テンプレート、入力欄、表示処理 | 引き継ぐ機能と管理方法 |
| SEO関連 | タイトル、説明文、OGP、noindex等の出力元 | どの機能で引き継ぎ、どう確認するか |
| 問い合わせ・計測 | フォーム、通知、解析タグ、送信後の案内 | 切り替え前後に行う動作確認 |
全ページを一度に見るのは大変なので、最初は検索からの流入が多い記事、問い合わせにつながるページ、独自の装飾を多く使っている記事から見ていきます。そこで見つかった問題を手がかりに、同じ装飾や機能を使っているほかのページを調べていくと、確認の漏れを減らせます。
乗り換えサポートプラグインを使いながら、記事を直していく
SWELLには、特定の旧テーマからの乗り換えを補助する公式プラグインがあります。公式の説明を要約すると、旧テーマの装飾やショートコードの一部を引き継いで、記事をSWELL用に書き換え終えるまでの負担を軽くするための仕組みです。どのテーマに対応し、どこまで引き継げるかは、公式の乗り換えサポートプラグイン一覧で確認します。
乗り換え補助の対応範囲
対象のテーマであっても、独自に追加したコードまで、あるいはすべての装飾を引き継げるわけではありません。自社のサイトで使っている機能が対応範囲に入っているかは、事前に確かめておいてください。対象外のテーマでは、同じ補助を使えるとは限りません。
補助プラグインを使うなら、公開前の確認はプラグインを入れた状態で行います。そして記事を書き換えたあとに、プラグインを止めても必要な内容が表示されるかをもう一度確かめます。書き換えたつもりでも、補助プラグインがないと表示できない記事が残っていることがあるからです。
どの記事から直すか、一覧にしておく
記事が多いと、どこまで確認したかを記憶で追いかけるのは無理があります。URL、使っている独自の表現、書き換えが必要かどうか、確認した日、残っている問題を一覧にしておきます。「見た目は変わったが読める」と「申込ボタンが押せない」とでは、対応の優先度が違います。
全記事をすぐに書き換えられないなら、重要なページの不具合を先に片づけ、残りの作業範囲と期限はそのあとで決めます。補助プラグインをいつまで使い、どこまで直したら外すのかも、あわせて決めておくと進めやすくなります。
SEOの設定が、移行後のページにも出ているかを確かめる
記事のタイトル欄がそのまま残っていても、検索結果向けのタイトルや説明文が以前と同じように出力されるとは限りません。まず、その設定を以前のテーマが持っていたのか、SEOプラグインに保存していたのかを確認します。設定画面に値が残っていても、ページのHTMLに出ていなければ、引き継げたことにはなりません。確認は実際のページで行います。
SWELLの公式サイトでは、OGPなどのmetaタグを扱う機能はプラグインで補う構成が説明されています（公式仕様の要約）。参考：推奨プラグインと非推奨・不要・注意すべきプラグインについて。今のSEOプラグインをそのまま使い続けるか、別のプラグインへ設定を移すかは、保存されている情報を確認してから決めます。
- 検索向けの出力代表ページのタイトル、meta description、canonical、noindexの有無、OGP画像を移行前後で比べます。
- URLと旧ページからの案内URLを変えない予定なら、実際に同じURLで開けるかを確かめます。変える必要がある場合は、旧URLから新しいページへの案内方法も用意します。
- 検証環境の設定検証環境のために入れたnoindexの設定が、本番に持ち込まれていないか。これも切り替え時の確認項目に入れておきます。
テーマをSWELLに変えただけで、検索順位が上がるとは言えません。先に考えるべきなのは、これまでの記事やリンクを引き継ぎ、URLやSEOの設定が意図せず変わらないようにすることです。公開後はSearch Consoleで重要なページの状態や流入を見ていきますが、数字が動いても、すぐにテーマ変更だけが原因だと決めつけないようにします。
検証環境でページを見て、問い合わせも送ってみる
検証環境には、本番サイトのファイルとデータベースを両方そろえて複製します。WordPress公式のバックアップの説明でも、この二つが挙げられています。参考：WordPress公式「Backups」。記事の本文だけをコピーしても、独自のコードやプラグインが移行後に動くかどうかまでは試せません。
検証環境をインターネット上に置くなら、関係者だけが見られるようにアクセスを制限し、検索結果にも出ないようにしておきます。問い合わせメールの宛先や外部サービスとの接続先も、テスト用に変えておきます。本番から複製した設定のままテスト送信してしまわないよう、作業の前に一度見直しておくと安心です。
見るのはトップページだけではありません。主要なサービスページ、記事、カテゴリー一覧、サイト内検索の結果、問い合わせページも開いてみます。PCとスマートフォンの両方でメニューやリンクを実際に操作し、フォームから送った内容がテスト用の宛先に届くところまで確かめて、見た目と動作の両方を確認します。
本番を切り替える日時と、不具合が出たときの戻し方
検証が終わってから本番を切り替えるまでの間にも、記事が更新されたり、問い合わせが保存されたりすることがあります。検証環境の古いデータベースで本番を丸ごと上書きするやり方だと、その間に増えた情報が失われるおそれがあります。何を本番に反映するのかを決めてから、作業に入ります。
- 切り替え前の状態を残す切り替える直前にバックアップを取り、サイトの更新を止めておく時間帯を決めます。
- 作業中と直後の担当を決める作業中に届いた問い合わせをどう扱うか、切り替え後に誰が確認するかを決めます。
- 戻す条件を決める「問い合わせが送れない」「主要なページが開かない」など、業務にどう響くかを基準に、具体的な条件にしておきます。
元のテーマに戻せば復旧する、とは限りません。本文を書き換えたり、プラグインの設定を変えたりしていれば、その分も戻す必要があります。何をどう戻すかを検証環境で確かめ、復旧に必要なものがそろってから本番を切り替えます。
grandworkに移行をご相談いただく際は、現在のサイトのURL、使っているテーマ、記事数、独自の機能、残したい表示を教えてください。見た目を作り直す作業と、既存のコンテンツや設定を引き継ぐ作業を分けて整理します。
- 既存サイトからの移行既存記事や問い合わせへの影響を確かめてから、SWELLへ移行したい方へ。WordPressの移行・改修を相談する