オーダー家具サイトのリニューアル事例

テーブルは写真で見栄えがしても、購入者にはいくつも疑問が残ります。部屋に収まるか。長くできるか。価格は写真のテーブルのものか、小さいサイズのものか。無垢材家具のサイトをリニューアルしたときは、こうした疑問が設計の軸になりました。

このプロジェクトでは、長年運用してきたカタログをMODXからWordPressとWooCommerceへ移行しました。対象は、なめらかな仕上げの家具、古材風に加工した家具、基準となる標準モデル、住宅や商業空間向けのオーダー品です。難しかったのは、これらをすべて分かりやすくすることでした。長年の商品データ、写真、工房のノウハウを、家具選びを助け、見積もり依頼につながるサイトにまとめ直しました。

家具の売り方から出発する

ストアは問い合わせを中心に組み立てることにしました。標準モデルは顧客にとっての出発点になりますが、最終的な注文は、寸法、木材、仕上げ、数量、配送で変わることがあります。これらが決まる前に支払いを求めると、販売で大切な過程を飛ばしてしまいます。

それでもWooCommerceは適していました。カタログ、再利用できる属性、バリエーションを備えているためです。主なアクションは「このモデルについて問い合わせる」や「別サイズを依頼する」にできます。部屋全体の家具をそろえる購入者には候補リストも必要で、複数の商品をまとめて相談できるようにしました。

この判断で、競合調査の見方も変わりました。カテゴリー、商品、問い合わせという購入までの流れをたどり、寸法、価格、仕上げサンプル、施工事例、注文手順の説明があるかを見ました。カタログが大きくても、顧客が理解できなければ意味がありません。比較で役に立ったのは、電話する前に訪問者がどれだけ分かるかでした。

調査では、最初のキーワード収集にも誤りがあると分かりました。工房が提供できる範囲を超えて、対象が広がっていたのです。そのバージョンは取り下げ、作り直した候補リストを実際の品ぞろえと照らして確認しました。家具に関連するフレーズでも、この事業のページを作る理由として不十分なことがあります。

主な構成は商品の種類にし、その次に素材、形、部屋、用途を検討しました。たとえば「円形ダイニングテーブル」は、カタログに合うモデルがあり、検索意図が明確なら、絞り込みページにする価値があります。レストラン向け家具のページは役割が異なります。相性のよい家具を選び、カスタマイズを理解し、大口の注文を伝えられるようにします。

旧カタログは移行前に使える状態へ整える

旧サイトには、公開ページから分かる以上の情報がありました。未公開のレコード、カスタムフィールド、ギャラリーの並び順、商品説明の中に埋め込まれた価格表です。まずデータベースのスナップショットとファイルのアーカイブを取り、元のテーブルからローカルのSQLiteインベントリを作りました。

元の値はクリーニング後のフィールドと並べて残し、すべてのレコードに変わらない旧IDを持たせました。これで、新しい商品を元のレコードまでたどれます。怪しい価格の確認や、欠けた写真の復元も、移行全体をやり直さずに済みます。

旧レコードにはそれぞれ移行先が必要でした。商品になるもの、別モデルのバリエーションになるもの、下書きのまま残すもの、確認のうえ廃止するものに分かれます。2つのサイトのカード総数を比べるだけでは、この区別が見えません。仕上げが複数ある親商品なら、選択肢を失わずに旧カード数枚の代わりになります。

zoom_in

データのクリーニングには、単純なインポートでは決められない判断が含まれます。たとえば「パイン、オークは要相談」は、基準となる素材とカスタムの選択肢を同時に表しています。両方を同じ樹種フィールドに入れると、絞り込みが誤解を招きます。スチールの脚は構造の項目、ステインの色は仕上げの項目に入れます。

名称、単位、表記はデータそのものの中で統一し、同じ値を絞り込み、仕様、商品説明で使えるようにしました。説明があいまいな箇所は、工房への確認事項として残しました。金具、寸法、構造の詳細は、写真では判断できないため、特に有効です。

zoom_in

AIによる分類は、説明文の仕分けと、確認が必要な属性の洗い出しに役立ちました。形の候補や表記のゆれを見つけるのに有効でした。ただし、正確な寸法、樹種、見えない金具には、文書による出典か職人の確認が必要です。そうしないと、見栄えのよい商品ページが推測に権威があるかのように見せてしまいます。

写真も商品データとして扱う

元の写真と、旧サイトが作った多数のサムネイルを分け、重複ファイルを確認し、ギャラリーの順序を保ちました。この順序は重要です。全体像で商品を紹介し、接写で接合部、取っ手、質感、仕上げを説明できるからです。

WebP版にするとギャラリーが軽くなり、元の画像もそのまま残せます。画像の編集にも、文章の編集と同じ注意が必要です。取っ手、接合部、プロポーションを変えると、顧客が思い描く注文内容が変わります。写真が小さすぎる、または商品がはっきり写っていない場合は、撮り直しを依頼するのが有効な次の一手でした。

1つのカタログに複数の入口をつくる

テーブルを探す顧客、ダイニングルームの家具をそろえる顧客、レストランを計画する顧客は、同じ商品を必要とすることがあります。こうした導線をナビゲーションに組み込み、商品レコードはモデルごとに1つにしました。

商品カテゴリーが基本の構造です。部屋別や業種別のページには、合うモデル、関連する施工事例、実用的なアドバイスを集めます。素材や形のページは、元のデータが裏付けられる範囲で選択を絞り込むのに役立ちます。同じ家具のコピーを複数管理せずに、購入時のさまざまな疑問に答えられます。

zoom_in

商品のURLと、カテゴリーツリー上の位置も切り離しました。商品にはカタログのプレフィックス以下に変わらないURLを持たせ、ナビゲーションとパンくずリストで所属を示します。後でモデルをより適切なカテゴリーに移しても、URLは変わりません。

検索用のページにする絞り込みを決める

絞り込みは、データが統一されていることが前提です。ある商品が「無垢オーク」、別の商品が「オーク材」、さらに別の商品が説明文にだけオークと書いていると、木材の絞り込みは信頼できません。再利用できる属性によって、カタログ全体で共通の語彙が得られました。

絞り込みの選択結果と、検索の入口となるランディングページは、似ていても目的が異なります。閲覧中は、顧客が条件を自由に組み合わせられるべきです。恒久的なランディングページには、有用な選択結果、明確な目的、選ぶ助けになる内容が必要です。あらゆる組み合わせがインデックス登録可能なURLを新たに作ってしまわないよう、承認済みページの一覧を明示的に管理しました。

クロールのルールにも、この区別を反映させる必要があります。並べ替えと絞り込みの組み合わせは一気に増えるため、計画段階ではGoogleのファセットナビゲーションに関するガイダンスが役立ちます。承認済みのランディングページは通常の閲覧状態と分けて扱い、それぞれについてcanonical URL、ページネーション、インデックス登録のルールを確認しました。

読む価値のある商品ページにする

最初の画面の役割はシンプルです。モデルを見せ、価格を説明し、主な仕様を示し、次の行動を分かりやすくします。残りのスペースでは、自分の部屋に置く場面を想像し始めた人が抱く疑問に答えられます。

価格の表示には特に注意が必要でした。「〜から」という価格は、対象のサイズと仕様を明記してこそ役に立ちます。オーダー品は見積もりが必要な場合もあります。価格がないものは、インポートでたまたま通ってしまった0円ではなく、見積もり対応であることを明示します。

寸法のラベルも適切にする必要があります。ベッドの外寸とマットレスのサイズは別のものです。キャビネットの幅、奥行き、高さも区別して示します。長さ単位で売る商品は、価格の横に単位を置きます。旧データの項目をすべて説明文にまとめてしまうと、こうした情報は失われやすくなります。

旧サイトの価格表は、説明文とは別に管理しました。商品まわりの文章を改善しても、料金を誤って消したり、意味を変えたりせずに済みます。カタログを更新するときに、価格情報を確認する場所もはっきりしました。

説明文では、目に見える構造、近い他のモデルとの違い、工房との相談が必要な選択を説明できます。文字数を増やすことより、次に出てくる当然の疑問に答えることのほうが重要でした。

実績を見せて、問い合わせしやすくする

家具メーカーでは、実績ページをカタログの近くに置くのが自然です。完成したダイニングルームなら、テーブル、椅子、仕上げがどう調和するかを示せます。そこから、使われているモデルへ戻る導線も作れます。逆に商品ページから、その商品が置かれた施工事例へ案内すれば、顧客は実際の空間での見え方を確認できます。

工房、スタッフ、ショールーム、レビューの各セクションも同じ考え方で作りました。購入者が判断できる具体的な材料を示します。製作中の写真は、家具の作り方を伝えます。スタッフ紹介は、設計、製作、問い合わせ対応の担当者を明らかにします。施工事例の説明では、依頼内容、素材、紹介する作業を書けます。

zoom_in

こうしたセクションは、事業ならではの具体的な情報があるほど効果的です。出どころの分からないギャラリーを飾り立てた物語より、実在する施工事例の短い紹介のほうが役に立ちます。レビューも同じです。抜粋の出典を示し、顧客が評価しているのが会社なのか特定の商品なのかを明確にします。

素材ガイドや用語集は、放っておくと販売の流れを止めてしまう疑問に答えられます。仕上げのガイドは仕上げの選択肢の横に、お手入れの記事は該当する商品の横に置きます。こうしたリンクもカタログの一部として設計し、アドバイスが必要な場所で見つかるようにしました。

顧客の選択を問い合わせに引き継ぐ

問い合わせの入口は主に3つ用意しました。1つのモデルについて質問する、候補リストを送る、オーダーの案件を説明する、です。どれも、顧客が既に持っている情報から始まります。商品ページにいる人が、商品名を空白の問い合わせフォームにコピーする必要はありません。

オーダー案件のフォームでは、連絡先を集める前に、希望する家具、おおよその寸法、素材、数量、設置場所を尋ねます。項目は、依頼内容を説明する助けになるものにします。適した木材や正確な寸法がまだ分からない人にも、相談を始める手段が必要です。

zoom_in

モバイルでは、カテゴリーを開く、絞り込む、ギャラリーを見る、モデルを保存する、問い合わせを送る、という一連の流れを通しで確認しました。選択中の絞り込み条件は見え続ける必要があります。パネルを閉じたら、顧客を適切な位置に戻します。画面に固定する問い合わせボタンは、周囲に余白を取り、最後の仕様やフォームのエラーを隠さないようにします。

メニューからのクリックだけでなく、商品URLやカテゴリーURLへの直接アクセスもテストしました。フォームは、選択したモデル、バリエーション、数量を保存される問い合わせに引き継ぐ必要があります。送信完了のメッセージは、何かが起きたことを顧客に伝えるだけです。工房が回答するには、正しい情報が必要です。

配送、支払い、納期、お手入れの情報も、この導線の途中に置きます。購入者が長い問い合わせを書き終えてから条件を知るのではなく、商品を検討している間に該当する条件を見つけられるようにします。

新サイトの構築と並行して移行を計画する

カタログの整理は、リダイレクトマップの土台にもなりました。新しいレコードにはどれも旧IDが残っているため、旧商品のURLと移行先を結び付け、例外を確認できました。統合したモデル、廃止したレコード、変更したカテゴリーです。

データベースのインベントリに、旧サイトのサイトマップ、クロールデータ、ウェブマスター向けのデータを組み合わせました。転送先は、訪問者が見つけると期待していたものと合っている必要があります。統合した商品なら後継の商品へ転送できます。販売終了したモデルを無関係のホームページへ転送するのは不適切です。URLのマッピングと移転時の確認事項は、Googleのサイト移転ガイドで説明されています。

内部リンクは、新しいURLへ直接向けます。画像も移行計画に含めました。インポートで商品自体は残っても、ギャラリーの半分が失われることがあるためです。リダイレクトのテストでは、HTTPとHTTPS、ホストのバリエーション、旧パスのパターンを含め、最終的なレスポンスを確認します。

zoom_in

SEOの出力を一貫させる

構造化データのグラフはテーマの担当にし、選んだメタデータのフィールドはSEOプラグインの担当にしました。これで、システムの異なる部分が商品や組織について矛盾した記述を出すことを避けやすくなりました。

同じ商品の事実は、表示されるページ、メタデータ、構造化データで一致している必要があります。見積もり専用のモデルに、0円のオファーが付いてはいけません。会社のレビューを、すべての商品の評価としてコピーするのもいけません。実装は、実際のページの内容とあわせて、GoogleのProduct構造化データのドキュメントに照らして確認しました。

リリースそのものには、明確なロールバック地点を持つ短い手順を使います。新しいカタログ、サーバー設定、問い合わせの処理が連動する必要がある場合でも、移行を管理しやすくなります。

計測にも、移行と同じ注意が必要です。旧サイトのアナリティクスを確認して基準値を決め、電話のクリック、フォームの送信、見込みのある問い合わせを分けて数えました。電話番号のクリックは計測する価値がありますが、実際に会話があったかどうかは分かりません。

移行後は、全体のトラフィックだけでなく、ランディングページの種類、デバイス、クエリのグループも比較します。この種の事業で次に問うのは実務的なことです。工房が依頼内容を理解し、見積もりを用意し、すぐに返信できるか。この引き継ぎを追跡すると、次の改善がWebサイトにあるのか、注文プロセスにあるのかが分かります。

よくある質問