JetEngineで不動産サイトを作るなら何をデータ化するべきか

不動産サイトをElementorだけで作ろうとすると、最初は物件紹介ページを1枚ずつきれいに作れます。写真を置いて、価格を書いて、間取りや駅徒歩をテキストで並べる。数件ならそれで十分です。ただ、物件数が増えた瞬間に、更新のしんどさが出てきます。

この記事では、JetEngineを使って物件情報をページではなくデータとして持つ考え方を整理します。完成形は、物件一覧、物件詳細、条件検索の入口を持つ小さな不動産サイトです。検索や地図まで一気に全部作る話ではなく、まず何をデータ化しておくと後で崩れにくいかに絞ります。

JetEngineの公式ページでも、動的サイト構造、一覧、クエリ、プロフィール、フィルター連携などが紹介されており、不動産デモでは物件詳細ページや物件カタログ、絞り込みを中核にした構成が示されています。ここで考えるべきなのは、プラグイン名を覚えることより、物件情報をどの単位で分けるかです。

JetEngine公式ページを見てみる

この記事で分かること

• 不動産サイトで最初に作るべきデータの箱（CPT）の考え方
• 価格、所在地、間取りなどを入力項目に分ける理由
• Elementorで物件カードと物件詳細を表示する流れ
• Query Builderや絞り込み検索を後から足しやすい設計
• 会員情報や契約管理まで広げる前に注意する境界線

まず何を作るのか

今回の例では、賃貸・売買の物件を管理するミニ不動産サイトを作ります。データの箱（CPT）は property、管理画面の表示名は「物件」とします。1件の投稿が1つの物件です。固定ページを物件ごとに増やすのではなく、物件CPTに情報を入れて、一覧と詳細ページに流し込みます。

ページ構成は3つです。1つ目は「物件一覧」。ここに公開中の物件カードを並べます。2つ目は「物件詳細」。写真、価格、所在地、間取り、面積、駅徒歩、特徴を表示します。3つ目は「エリア別・条件別の検索導線」。最初は簡単なリンクやQuery Builderで始め、必要になったら絞り込み検索（JetSmartFilters）を足します。

ここで少し迷いやすいのは、「物件説明」の長文に全部書けば早いのでは、という判断です。たしかに1件だけなら早いです。でも価格で並べ替える、エリアで探す、公開中だけ出す、駅徒歩10分以内だけ見せる、という運用を考えると、長文に埋め込んだ情報は使い回しにくくなります。

JetEngineでどのデータを持たせるのか

物件CPTには、検索・並び替え・一覧表示に使う情報を分けて持たせます。入力項目として分けるかどうかの判断基準は、「後で条件に使うか」「一覧カードで別々に見せるか」「担当者が更新しやすいか」です。

価格は文字ではなく数値で持つのが大事です。「4,980万円」と文字で入れると見た目は自然ですが、価格順や範囲検索が面倒になります。入力は 49800000、表示時に「4,980万円」のように整える方が、後から使いやすいです。

所在地も悩みどころです。住所全文を1つのテキストにすると、地図表示やエリア検索に使いにくくなります。最初は「都道府県」「市区町村」「町名」まで細かく分けすぎる必要はありませんが、少なくとも検索で使う粒度は別項目にしておきます。たとえば小規模サイトなら property_area をSelectにして、「渋谷区」「新宿区」「世田谷区」のような選択肢から選ばせるだけでも管理しやすくなります。

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

Elementor側では、1件分の物件カードを作ります。これが一覧テンプレート（Listing Item）です。カード内にはDynamic Imageで物件画像、Dynamic Fieldで価格や駅徒歩、Dynamic Linkで詳細ページへのリンクを配置します。公式ドキュメントでも、Listing GridはCPTやカスタムフィールドのデータを動的に表示するためのウィジェットとして説明されています。

カードの構成例はシンプルで構いません。上に物件画像、下に物件名、価格、エリア、駅徒歩、間取り、ステータスバッジ。最初から比較表、地図、スライダー、会員限定表示を全部入れると、どこで崩れているのか分からなくなります。まずは「一覧で同じ型のカードが自動で増える」状態を作るのが先です。

一覧ページにはListing Gridを置き、対象を物件CPTにします。表示件数は最初なら12件程度、列数はPCで3列、タブレットで2列、スマホで1列のように考えます。物件画像の縦横比がばらばらだとカードの高さが崩れやすいので、Elementor側の画像比率やカード高さも確認します。ここは地味ですが、実際に見た目が乱れやすいポイントです。

Query Builderで公開中の物件だけ出す

物件一覧では、すべての物件を出せばよいわけではありません。成約済みの物件を残したいけれど、一覧の主役にはしたくない場合があります。そこでQuery Builderを使い、公開中の物件だけを取得するクエリを作ります。

設定例として、Query名は property_available_query、Query TypeはPosts Query、Post Typeは property。Meta Queryでは property_status が 公開中 と等しいものだけにします。さらに価格順で見せたいなら、Order ByにMeta Value Numeric、Meta Keyに property_price を指定します。

公式ドキュメントでは、Query BuilderのクエリはListing GridのCustom Queryタブで選べると説明されています。ElementorではListing GridのCustom Queryを有効にして、先ほど作った property_available_query を選びます。ここまで作ると、担当者は物件の公開状態を変えるだけで、一覧に出す・出さないを切り替えられます。

絞り込み検索を入れる前に決めること

不動産サイトでは、エリア、価格帯、間取り、駅徒歩、築年数などの絞り込みを作りたくなります。ここで必要になりやすいのが、絞り込み検索用の別プラグイン（JetSmartFilters）です。ただし、検索UIを入れる前に、JetEngine側の入力項目が検索に耐えられる形になっているかを見直します。

価格が文字列、間取りが自由入力、エリアが住所全文だけ、ステータスが担当者ごとに「公開」「公開中」「掲載中」と揺れている。この状態で検索UIを作ると、見た目はできても結果が安定しません。まずは選択肢をそろえ、数値は数値として保存します。少し面倒ですが、ここを飛ばすと後から直す範囲が大きくなります。

最初の検索は、すべての条件を入れなくて大丈夫です。たとえば「エリア」「価格帯」「間取り」の3つだけで始めます。駅徒歩、築年数、こだわり条件、地図検索は、物件数と読者の探し方を見ながら追加します。検索条件が多いほど便利に見えますが、項目が空欄だらけだと逆に使いにくくなります。

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

静的なElementorページでは、物件が増えるたびにページを複製し、画像とテキストを差し替え、一覧ページにも手作業でカードを追加します。成約済みになったら詳細ページを残すか消すか、一覧のカードを消すか、関連リンクをどうするかも手で管理します。

JetEngineで物件CPTを作ると、担当者は「物件を追加」画面から入力します。写真を登録し、価格や間取りを入力し、公開状態を選びます。Elementor側のカードや詳細ページは同じ型を使うので、見た目のルールが揃いやすくなります。運用面では、デザイン編集と物件登録を分けられるのが大きいです。

管理画面の作業手順は、1. 物件を追加、2. 入力項目を埋める、3. 写真を登録、4. 公開状態を確認、5. 一覧と詳細をプレビュー、という流れです。慣れていない担当者が触るなら、必須項目を増やしすぎない方が安全です。未入力が多いと詳細ページに空欄が出るため、Dynamic Visibilityで「値があるときだけ表示」するルールも役立ちます。

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

不動産サイトは、物件一覧だけなら比較的作りやすいです。複雑になるのは、問い合わせ履歴、内見予約、担当者ごとの管理、会員限定物件、契約ステータス、顧客情報、メール通知、決済、外部ポータル連携まで入れ始めたときです。ここから先は、JetEngineの設定だけで済ませるというより、個人情報、権限、バックアップ、運用ルールを含めた設計が必要になります。

たとえば会員限定物件を作る場合、Dynamic Visibilityで表示を隠すだけでは十分とは限りません。HTMLに出ている情報、メディアファイルへの直接アクセス、検索結果への混入、キャッシュの扱いも見ます。ここは「見えないから安全」と考えない方がいいです。

管理画面で入力ミスを減らすルール

物件データは、入力担当者が毎回迷わない形にしておくことも大切です。たとえば価格欄の説明には「半角数字で入力。例：49800000」と書きます。駅徒歩は「分だけを数字で入力。例：5」とします。面積も「55.2」のように数字だけにします。見た目に出す単位はElementor側やショートコード側で付けます。

選択肢は、あとで検索条件になるものほど自由入力にしない方が安全です。間取りを自由入力にすると、「2LDK」「２ＬＤＫ」「2 LDK」「2LDK以上」のように表記が揺れます。小さな違いに見えますが、絞り込み検索では別の値として扱われることがあります。最初は面倒でも、SelectやCheckboxで選択肢を固定しておく方が後で直しやすいです。

公開状態も同じです。「公開中」「商談中」「成約済み」の3つに絞るなら、それ以外の言葉を担当者が入力できないようにします。ステータスバッジの色はElementor側で整え、データ側には状態だけを保存します。ここを混ぜると、デザインを変えたいだけなのに物件データまで触ることになります。

公開前に確認したい表示チェック

物件CPTを作ったら、最低でも3種類のサンプルを登録して確認します。価格の高い物件、価格の低い物件、写真が少ない物件です。写真が1枚しかない物件でカードが崩れないか、価格が未入力の物件で不自然な空白が出ないか、成約済みの物件が一覧に混ざらないかを見ます。

スマホ表示も早めに確認してください。不動産サイトは写真、価格、間取り、駅徒歩、所在地を一度に見せたくなりますが、スマホのカードに詰め込みすぎると読みにくくなります。カードには判断に必要な情報だけを置き、詳しい説明は詳細ページに送る方が自然です。ここはデザインの好みではなく、運用後に物件が増えたときの読みやすさに関わります。

最後に、検索条件を増やす前に「未入力データがあるとどうなるか」を試します。築年数が空欄の物件、駅徒歩が不明な物件、価格が相談の物件をどう扱うか。実際の不動産情報では、すべての項目が毎回きれいに埋まるとは限りません。未入力時の表示ルールを決めておくと、後から担当者が困りにくくなります。

画像の登録ルールも決めておくと安定します。外観写真を1枚目、室内写真を2枚目以降、間取り画像は別枠で登録する、というように順番をそろえます。担当者ごとに写真の順番が変わると、一覧カードの印象も詳細ページの見やすさもぶれます。JetEngineの入力項目だけで解決する話ではありませんが、データ設計と運用ルールはセットで考えた方がよいです。

物件名も自由に付けすぎない方が扱いやすいです。「渋谷区のきれいなマンション」のような説明文をタイトルにすると、一覧では読みにくく、検索結果でも揃いません。内部管理用には物件番号 property_code を持たせ、表示タイトルは短く整える。こうした地味なルールが、物件数が増えたときの管理しやすさにつながります。

担当者向けの入力メモも効果があります。「商談中にしたら一覧には残すが、問い合わせボタンは隠す」「成約済みは詳細ページを残すが、おすすめ一覧には出さない」のように、状態ごとの扱いを書いておきます。設定そのものより、運用時の迷いを減らすことが大事です。

この構成が向いている人、向いていない人

向いているのは、Elementorで不動産会社のサイトや物件紹介サイトを作り、物件数が増えても一覧と詳細をきれいに保ちたい人です。特に、同じ項目を何度も手入力しているなら、JetEngineでデータ化する意味があります。

向いていないのは、最初から大規模な不動産ポータル、複数店舗の権限管理、顧客管理、契約管理、レインズのような外部業務システム連携まで一気に作りたいケースです。その場合は、要件定義、セキュリティ設計、パフォーマンス検証、カスタム開発の範囲を先に切り分ける必要があります。

まとめ

JetEngineで不動産サイトを作るときは、最初に物件情報をどの単位でデータ化するかを決めます。物件CPT property を作り、価格、所在地、間取り、駅徒歩、面積、築年数、公開状態、画像を分けて持たせる。Elementor側では1件分のカードと詳細テンプレートを作り、Listing Gridで繰り返し表示する。この順番なら、静的ページから一歩進めやすくなります。

逆に、検索、会員限定、予約、契約管理まで最初から全部入れると、初心者には見通しが悪くなります。まずは公開中の物件一覧と詳細ページを安定させ、必要な条件だけを追加する。小さく始める方が、後で直しやすい不動産サイトになります。

JetEngine公式ページを見てみる