JetEngineで店舗マップ一覧を作る具体例

店舗一覧をElementorで作るとき、最初は店舗名と住所をカードに並べるだけでも十分に見えます。ただ、店舗数が増えると「この店舗はどこにあるのか」「近い店舗だけ見たいのか」「一覧と地図の内容がずれていないか」が気になってきます。今回作るのは、JetEngineで店舗情報を管理し、Elementor側でカード一覧と地図を同じデータから表示する小さな店舗マップ一覧です。

結論から言うと、ポイントは地図ウィジェットの見た目よりも、WordPress側に店舗データを分けて持たせることです。住所を1つの文章欄にまとめるのではなく、店舗名、住所、地図位置、営業時間、エリア、詳細ページへのリンクを項目として分けます。これができると、後から営業時間だけ直したいときも、店舗カードと地図ピンの両方を同じ修正で更新できます。

JetEngine公式ページを見てみる

この記事で分かること

• JetEngineで店舗用のデータの箱（CPT）を作る考え方
• 地図表示に必要な入力項目と、後で困りやすい項目の分け方
• Elementor側で店舗カードとMap Listingを組み合わせる流れ
• 一覧、地図、詳細ページを同じデータから動かす運用の利点
• 現在地検索や大量ピンなど、最初から入れすぎない方がいい範囲

まず何を作るのか

例として、地域に複数店舗を持つスクールやサロンの「店舗一覧ページ」を作ります。静的なElementorページなら、地図画像を貼り、店舗カードを手で増やしていく形でも作れます。3店舗くらいならそれでも問題は少ないです。ですが、店舗が増えたり、営業時間や受付状態が変わったり、エリアごとの表示をしたくなったりすると、手作業の修正がすぐに重くなります。

今回のサンプルでは、データの箱（CPT）名を store、表示名を「店舗」とします。1件の店舗投稿に、住所や営業時間などを入力し、その情報を一覧テンプレートと地図に流し込みます。Elementorでは1件分の店舗カードを作り、Listing Gridで複数件を並べ、Map Listingで同じ店舗投稿を地図上のピンとして表示します。

JetEngineで持たせる店舗データ

店舗マップ一覧で最初に決めるべきなのは、ページのデザインではなく入力項目です。あとから絞り込み検索や近隣表示を足したくなる場合、住所を本文に直接書いてしまうと再利用しにくくなります。JetEngineのCustom Post Typeで「店舗」を作り、Meta Fieldsで必要な項目を分けておくと、表示や検索の土台が安定します。

ここで迷いやすいのは、住所と地図位置の扱いです。住所欄だけを作っておけば地図も出る、と思いたくなりますが、実務では住所の表記ゆれやビル名の違いでピンがずれることがあります。公式ドキュメントでもMap Listingは地図用のフィールドやMap Listingウィジェット設定と組み合わせて扱う前提になっています。住所は人が読む情報、地図位置は地図が読む情報、と分けて考える方が安全です。

Elementor側ではどう表示するのか

Elementor側では、まず1件分の店舗カードを作ります。JetEngineの一覧テンプレート（Listing Item）で、店舗名、住所、営業時間、詳細リンクをDynamic FieldやDynamic Linkで差し込みます。この1件分の見た目を作ってから、Listing Gridで複数店舗を並べます。次にMap Listingを配置し、同じ店舗投稿を地図ピンとして表示します。

レイアウトは、PCでは左に店舗カード、右に地図を置く2カラムが分かりやすいです。スマホでは地図を上に置くか、カード一覧を先に見せるかを検討します。店舗を探している人は地図から入りたい場合もありますが、営業時間や特徴を比較したい人はカード一覧の方が読みやすいです。どちらを優先するかは、サイトの目的で変わります。

設定としては、Listing Itemに「店舗カード」を作り、Map Listing側では地図の中心、ズーム、ピンに使うフィールド、ピンをクリックしたときの表示内容を確認します。ピンのポップアップに長い説明を詰め込みすぎると読みにくいため、店舗名、短い住所、詳細リンクくらいに抑えるのが現実的です。

表示条件と並び順を決める

店舗マップ一覧では、すべての店舗をただ出すだけなら簡単です。実務で大事なのは「公開してよい店舗だけ出す」「地図位置が入っている店舗だけ出す」「必要に応じてエリア別に見せる」といった条件です。JetEngineのQuery Builderや表示条件を組み合わせると、一覧に出す店舗の範囲を管理しやすくなります。

たとえばQuery Builderで post_type = store を指定し、reception_status = open、さらに store_location が空ではない店舗だけを対象にします。これなら、まだ住所確認中の店舗や、準備中の店舗を誤って地図に出すリスクを減らせます。公開前の店舗を下書きにしておく運用でもよいですが、店舗一覧だけ一時的に非表示にしたい場面では状態フィールドが役に立ちます。

後から絞り込み検索を入れるなら、エリアやサービス種別を分類項目として用意しておくと楽です。ただし、最初から価格帯、設備、スタッフ、駅徒歩、駐車場、対応メニューまで細かく分けると、入力する側が続きません。まずは運用で本当に更新する項目だけに絞るのが安全です。

運用すると何が楽になるのか

静的なElementorページでは、店舗の営業時間が変わるたびに、一覧カード、地図下の説明、店舗詳細ページなどを別々に直すことがあります。JetEngineで店舗データを中心にすると、修正箇所が1件の店舗投稿に集まります。新店舗を追加するときも、店舗投稿を1件作り、必要な入力項目を埋めれば、一覧と地図に反映しやすくなります。

運用担当者にとって分かりやすいのは、Elementorのデザイン編集画面を毎回触らなくてよい点です。デザインは制作者がListing Itemで整え、更新担当者はWordPressの「店舗」投稿を編集する。役割を分けられます。これは小さな差ですが、店舗数が増えたときの事故をかなり減らせます。

管理画面側の入力手順を先に決める

店舗マップ一覧は、公開画面だけを見ると「地図にピンが立つかどうか」が中心に見えます。けれど、実際に長く使うなら、管理画面で誰が何を入力するかを先に決めておく方が重要です。たとえば新店舗を追加する流れを、1. 店舗名を入れる、2. 住所を入れる、3. 地図位置を確認する、4. 営業時間を入れる、5. エリアを選ぶ、6. プレビューで地図ピンを確認する、という順番にします。この順番を決めないまま項目だけ作ると、地図位置が空の店舗や、住所表記だけ違う店舗が混ざりやすくなります。

更新担当者が迷いやすい項目には、フィールド説明を入れておくと親切です。たとえば store_location には「Map Listingで使う位置です。住所を変更したら必ずピン位置も確認してください」と書いておきます。reception_status には「受付中だけ一覧に出す設定にする場合があります」と補足します。こうした説明は地味ですが、動的サイトではかなり効きます。Elementorで見た目を整えるより前に、入力ミスが起きにくい管理画面を作る感覚です。

また、店舗写真を使う場合は画像サイズも決めておきます。カードごとに縦横比が違う写真を入れると、Listing Gridの高さが不揃いになりやすいです。JetEngine側の項目として店舗写真を1枚持たせ、Elementor側では画像比率をそろえて表示します。写真が未登録の店舗をどう見せるかも先に決めておくと、公開直前に慌てません。

静的Elementorページとの違い

静的なElementorページでは、店舗カードの数だけセクションやカラムを複製して作ることが多いです。見た目は自由ですが、情報が増えるほど「どこを直せば全部直るのか」が分かりにくくなります。店舗名を変更したのに、別のセクションに古い名称が残る。営業時間だけ更新したつもりが、地図下の説明文は古いまま。こういうズレが起きやすいです。

JetEngineを使う場合は、店舗情報をWordPress側の1件の投稿に集め、Elementorはその情報を表示する役になります。つまり、Elementorはデザインを作る場所、JetEngineは店舗データを管理する場所、と役割を分けます。最初は少し遠回りに見えますが、店舗数が5件、10件、20件と増えるほど差が出ます。同じ情報を何度も手入力しないことが、動的化する一番分かりやすい価値です。

実装前のチェックリスト

• 店舗を追加・修正する担当者は誰か
• 住所と地図位置を確認する手順を誰が持つか
• 準備中店舗を一覧に出すのか、完全に隠すのか
• スマホでは地図とカードのどちらを先に見せるか
• 店舗が増えたとき、エリアで分ける必要があるか
• 現在地検索や予約導線を初期公開に含めるか、後回しにするか

このチェックを先に済ませると、JetEngineの設定がかなり決めやすくなります。逆に、運用ルールが曖昧なままフィールドだけ増やすと、後で「この項目は誰も使っていない」「この条件で非表示にすると困る店舗がある」という状態になりがちです。最初の設計では、欲張らずに公開画面と更新作業の両方で使う項目だけに絞ってください。

どこから複雑になりすぎるのか

店舗マップ一覧は、やろうと思えばかなり広げられます。現在地から近い順、複数条件の絞り込み、地図を動かした範囲で一覧を更新、予約フォーム連携、会員別の表示などです。Crocoblock公式にも地図の範囲更新や現在地検索に関するチュートリアルがありますが、最初の構成に全部入れると、設定項目もテスト範囲も一気に増えます。

特に大量ピンは慎重にした方がいいです。店舗数が多い場合、地図の読み込み、フィルターの反応、スマホ表示、キャッシュとの相性を確認する必要があります。JetEngineはデータ構造と表示をつなぐ強い土台になりますが、パフォーマンス設計や個別の検索体験まで自動で解決してくれるわけではありません。

公開前に確認したい表示崩れ

店舗マップ一覧は、きれいに作ったつもりでも実データを入れると崩れることがあります。住所が長い店舗、営業時間が曜日ごとに細かい店舗、店舗名が長い店舗、写真が未登録の店舗。こうした例を少なくとも3件から5件はテスト投稿として入れてください。サンプルがきれいすぎると、公開後の実データでカードの高さや地図ポップアップが崩れます。

スマホ確認も必須です。PCでは地図と一覧を横並びにできても、スマホでは地図が大きくなりすぎたり、カードの詳細リンクが押しにくくなったりします。Map Listing自体の設定だけでなく、Elementorのレスポンシブ設定、余白、カラム順、ピンをタップしたときのポップアップも見てください。ここは少し面倒ですが、店舗一覧はスマホで見られることが多いので後回しにしない方がいいです。

もう一つ見落としやすいのが、店舗を閉店・移転したときの処理です。閉店した店舗を削除してしまうと、過去のお知らせや関連ページからリンク切れになることがあります。削除ではなく受付状態を「終了」や「非表示」にして、必要なら詳細ページだけ残す運用も考えられます。移転の場合は住所と地図位置を両方直し、旧住所が本文や画像内に残っていないかも確認します。JetEngineで管理していても、画像に住所を書き込んでしまうとそこだけ手修正になるので、店舗情報はできるだけ入力項目から出す方が後々楽です。

制作側の納品メモには、どのフィールドがどの表示に使われているかを書いておくと親切です。「店舗名はカード見出しと地図ポップアップ」「地図位置はMap Listing」「受付状態は一覧表示条件」のように短く残しておけば、数か月後に修正する人が迷いません。動的サイトは作った瞬間より、更新が続いた後に設計の良し悪しが見えます。小さなメモでも、保守時の安心感はかなり変わります。更新担当者にも伝えやすくなります。

この作り方が向いている人、向いていない人

向いているのは、店舗数が増える可能性があり、一覧カードと地図を同じ情報から管理したいサイトです。スクール、サロン、クリニック、ショールーム、地域拠点一覧などは相性がよいです。逆に、1店舗だけで地図を置けば十分なサイトなら、Googleマップの埋め込みと通常のElementorセクションだけで済むこともあります。

また、会員だけに一部店舗を見せる、予約状況と連動させる、個人情報を含む拠点を扱う、といった場合は設計が別物になります。権限、プライバシーポリシー、バックアップ、スパム対策、表示テストを先に決めてください。ここを曖昧にしたまま動的化すると、便利さより管理リスクが勝ちます。

まとめ

JetEngineで店舗マップ一覧を作るときは、地図の見た目から入るより、まず店舗データをどう持つかを決める方が失敗しにくいです。データの箱を store として作り、住所、地図位置、営業時間、エリア、受付状態を分けておく。Elementor側では1件分の店舗カードを作り、一覧と地図に同じ店舗データを流し込む。この順番なら、静的な店舗紹介ページから一歩進めます。

最初は、公開中の店舗だけを一覧と地図に出すところまでで十分です。現在地検索や高度な絞り込みは、運用が回ることを確認してから足す方が安全です。

JetEngine公式ページを見てみる