AI Search-এ Real Estate Listing Page: কেন লুকিয়ে থাকে এবং Geo Data

রিয়েল এস্টেট তালিকা পোর্টালগুলি মান AEO playbook অনুসরণ করছে। তাদের ল্যান্ডিং পৃষ্ঠায় FAQ স্কিমা রয়েছে। তাদের হোমপেজে LocalBusiness মার্কআপ রয়েছে। তারা দীর্ঘ-লেজ প্রশ্ন লক্ষ্য করে কথোপকথনমূলক কনটেন্ট লিখেছে। এবং তাদের বেশিরভাগ এখনও প্রদর্শিত হয় না যখন কেউ একটি AI ইঞ্জিনকে "[শহর]-এ বিশ্ববিদ্যালয়ের কাছাকাছি 2-শয়ন অ্যাপার্টমেন্ট" জন্য জিজ্ঞাসা করে।

কারণটি কাঠামোগত, প্রসাধনী নয়। তালিকা পৃষ্ঠাগুলি কনটেন্ট পৃষ্ঠা নয়। সম্পাদকীয় কনটেন্টের জন্য ডিজাইন করা AEO কৌশলগুলি তালিকা সংগ্রহের জন্য প্রয়োগ করা হয় না। এই গাইড তালিকা প্ল্যাটফর্ম অপারেটরদের জন্য লেখা: রিয়েল এস্টেট পোর্টাল, ছুটির দিন ভাড়া সাইট, অ্যাপার্টমেন্ট মার্কেটপ্লেস। ব্যক্তিগত এজেন্টদের জন্য নয়। হোটেল দৃশ্যমানতা সমস্যা থেকে চ্যালেঞ্জ আলাদা, কিন্তু মূল কারণ একই অনুপস্থিত geo ডেটা স্তর।

মান AEO পরামর্শ তালিকা পৃষ্ঠার জন্য কেন কাজ করে না

মান AEO পরামর্শ এটির মতো চলে: কথোপকথনমূলক কনটেন্ট লিখুন, FAQ স্কিমা যোগ করুন, দীর্ঘ-লেজ প্রশ্ন লক্ষ্য করুন, বিষয়গত কর্তৃত্ব তৈরি করুন। এটি ব্লগ পোস্ট, গাইড এবং ল্যান্ডিং পৃষ্ঠার মতো সম্পাদকীয় কনটেন্টের জন্য সঠিক। স্থানীয় ব্যবসার জন্য সম্পূর্ণ AEO গাইড সেই কৌশলগুলি ভালভাবে কভার করে।

তালিকা পৃষ্ঠাগুলি বিভাগ-স্তরের প্রশ্নের উত্তর দিচ্ছে না। তারা নির্দিষ্ট সত্তা প্রতিনিধিত্ব করছে: নির্দিষ্ট বৈশিষ্ট্য সহ নির্দিষ্ট অবস্থানে একটি তিন-শয়ন অ্যাপার্টমেন্ট, নির্দিষ্ট মূল্যে উপলব্ধ। AI ইঞ্জিনগুলি সত্তা পুনরুদ্ধার করে, প্রবন্ধ নয়।

যখন একটি ব্যবহারকারী Perplexity কে "Parc de la Villette এর কাছে 1500 ইউরোর অধীনে ভাড়া" জন্য জিজ্ঞাসা করে, AI ভৌগোলিক সত্তা মিলান করছে। এটি নির্দিষ্ট অবস্থান সহ তালিকা সত্তার জন্য অনুসন্ধান করছে একটি সমাধানযোগ্য ভৌগোলিক এলাকার মধ্যে, একটি কাঠামোবদ্ধ বৈশিষ্ট্য হিসাবে বিবৃত পরিসরের মধ্যে একটি মূল্য এবং জিজ্ঞাসিত ল্যান্ডমার্ক বা পাড়ার জন্য মেশিন-পাঠযোগ্য সম্পর্ক।

আপনার তালিকা পৃষ্ঠায় একটি FAQ ব্লক AI সেই ম্যাচ সম্পাদন করতে সাহায্য করে না। আপনার হোমপেজে একটি LocalBusiness স্কিমা আপনার URL কাঠামোর দুটি পৃষ্ঠা গভীর একটি ব্যক্তিগত তালিকা পুনরুদ্ধার করতে সাহায্য করে না। যে সত্তা মেশিন-পাঠযোগ্য হওয়া প্রয়োজন তা তালিকা পৃষ্ঠা নিজে।

একটি তালিকা পৃষ্ঠা থেকে AI ইঞ্জিনগুলি আসলে কী প্রয়োজন

একটি নির্দিষ্ট স্কিমা ধরন। Schema.org তালিকা সংগ্রহের জন্য ডিজাইন করা ধরন রয়েছে: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental। তালিকা পৃষ্ঠায় জেনেরিক LocalBusiness বা Article ব্যবহার করা তাদের রিয়েল এস্টেট প্রশ্নের জন্য ভুল সত্তা বিভাগে রাখে।

মূল্য নির্ধারণ এবং উপলব্ধতা কাঠামোবদ্ধ ডেটা হিসাবে। তালিকা ধরনের মধ্যে একটি Offer নেস্টেড AI ইঞ্জিনগুলি মূল্য সীমাবদ্ধতা অন্তর্ভুক্ত করে এমন প্রশ্ন বিপরীত তালিকা ম্যাচ করার জন্য প্রয়োজনীয় কাঠামোবদ্ধ মূল্য এবং উপলব্ধতা বৈশিষ্ট্য দেয়। শুধুমাত্র পৃষ্ঠার দৃশ্যমান পাঠে প্রদর্শিত একটি মূল্য একটি প্রশ্নযোগ্য বৈশিষ্ট্য নয়।

Geo ডেটা। এটি স্তর যা প্রায় প্রতিটি বাস্তবায়ন অনুপস্থিত এবং এটি পরবর্তী বিভাগে সম্পূর্ণভাবে কভার করা হয়েছে।

তিন Geo ডেটা ফাঁক

ফাঁক 1: তালিকা পৃষ্ঠা নিজেই উপর কোনো স্থানাঙ্ক নেই

সুনির্দিষ্ট GeoCoordinates latitude এবং longitude সহ কমপক্ষে চার দশমিক স্থান তালিকা পৃষ্ঠার নিজস্ব JSON-LD-এ প্রদর্শিত হতে হবে। ঠিকানা স্ট্রিংগুলি একটি প্রতিস্থাপন নয়। সাধারণ ভুল হল শুধুমাত্র একটি সাইট-স্তরের LocalBusiness স্কিমাতে geo প্রয়োগ করা হোমপেজে। ব্যক্তিগত তালিকা পৃষ্ঠাগুলি তাদের নিজস্ব সমন্বয় প্রয়োজন। প্রতিটি তালিকা একটি স্বতন্ত্র ভৌগোলিক সত্তা। যেকোনো তালিকা ধরনের জন্য এটি সঠিকভাবে কীভাবে বাস্তবায়ন করতে হয় তা JSON-LD স্কিমা গাইডে কভার করা হয়েছে।

ফাঁক 2: কোনো containedInPlace সম্পর্ক নেই

containedInPlace তালিকা পাড়া, জেলা এবং শহর সত্তা যা ভৌগোলিকভাবে এটি ধারণ করে তাদের সাথে সংযুক্ত করে। এটি শুধুমাত্র ঠিকানা-স্তরের প্রশ্নের জন্য নয় এলাকা-স্তরের প্রশ্নের জন্য তালিকা পুনরুদ্ধারযোগ্য করে তোলে।

এটি ছাড়া, একটি তালিকা আপনার স্কিমায় একটি রাস্তার ঠিকানায় বিদ্যমান কিন্তু কোনো নামযুক্ত ভৌগোলিক সত্তার সদস্য নয়। একটি AI ইঞ্জিন "[পাড়া নাম]-এ অ্যাপার্টমেন্ট" এর জন্য এটি পুনরুদ্ধার করতে পারে না কারণ তালিকা এবং সেই পাড়ার মধ্যে কোনো কাঠামোবদ্ধ লিঙ্ক নেই।

"containedInPlace": {
  "@type": "Place",
  "name": "Prenzlauer Berg",
  "containedInPlace": {
    "@type": "City",
    "name": "Berlin"
  }
}

ফাঁক 3: কোনো নিকটবর্তী স্থান ডেটা নেই

"S-Bahn এর কাছাকাছি ফ্ল্যাট" বা "ভাল স্কুলের কাছাকাছি বাড়ি" এর মতো প্রশ্নের জন্য নিকটবর্তী ভৌগোলিক বৈশিষ্ট্যগুলিতে কাঠামোবদ্ধ সম্পর্ক থাকার জন্য তালিকা প্রয়োজন। আপনার সম্পত্তি বিবরণে একটি বাক্য যথেষ্ট নয়। একই তথ্য একটি কাঠামোবদ্ধ Place সত্তা হিসাবে amenityFeature এর মাধ্যমে লিঙ্ক করা, ট্রানজিট স্টপের জন্য স্থানাঙ্ক এবং একটি দূরত্ব বৈশিষ্ট্য সহ, প্রশ্নযোগ্য।

তালিকা ডাটাবেস কেন এই ডেটা বহন করে না

বেশিরভাগ সম্পত্তি ব্যবস্থাপনা সিস্টেম এবং তালিকা ডাটাবেস যা অপারেটরগুলি প্রবেশ করে তা সংরক্ষণ করে: ঠিকানা, মূল্য, শয়ন, ছবি। এগুলি মানুষের জন্য একটি পোর্টাল ব্রাউজ করার জন্য নির্মিত। স্থানাঙ্ক, পাড়া সীমানা এবং কাছাকাছি POI ডেটা মান ক্ষেত্র নয়, কারণ তালিকা সফ্টওয়্যার কখনও AI পুনরুদ্ধার সিস্টেমে মেশিন-পাঠযোগ্য ভৌগোলিক প্রসঙ্গ সরবরাহ করার জন্য ডিজাইন করা হয়নি।

স্কেলে এই ফাঁক বন্ধ করার উপায় একটি ম্যাপিং API এর মাধ্যমে। Geocoding API গুলি ঠিকানাগুলি সুনির্দিষ্ট স্থানাঙ্কে রূপান্তরিত করে। পয়েন্ট-অফ-ইন্টারেস্ট API গুলি নির্দিষ্ট ব্যাসার্ধের মধ্যে ট্রানজিট স্টপ, স্কুল, পার্ক এবং ল্যান্ডমার্ক ফিরিয়ে দেয়। পাড়া সীমানা API গুলি সমাধান করে যে কোন ভৌগোলিক সত্তা একটি প্রদত্ত স্থানাঙ্ক ধারণ করে। আউটপুট সরাসরি schema.org ধরন ম্যাপ করে এবং স্কেল এ একটি বিল্ড-টাইম বা সার্ভার-সাইড প্রক্রিয়ার মাধ্যমে তালিকা পৃষ্ঠা JSON-LD এ এম্বেড করা যায়। AI বর্তমানে এই ধরণের ডেটা কীভাবে ওয়েবসাইটগুলি খুঁজে পেতে এবং মূল্যায়ন করতে ব্যবহার করে বৃহত্তর পুনরুদ্ধার মডেল ব্যাখ্যা করে।

একটি তালিকা পৃষ্ঠার জন্য সম্পূর্ণ স্কিমা কাঠামো

{
  "@context": "https://schema.org",
  "@type": "Apartment",
  "name": "3-room apartment, Prenzlauer Berg",
  "description": "Bright 3-room apartment, 78 sqm, renovated kitchen, south-facing balcony.",
  "numberOfRooms": 3,
  "floorSize": { "@type": "QuantitativeValue", "value": 78, "unitCode": "MTK" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Kastanienallee 42",
    "addressLocality": "Berlin",
    "postalCode": "10435",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.5384,
    "longitude": 13.4132
  },
  "containedInPlace": {
    "@type": "Place",
    "name": "Prenzlauer Berg",
    "containedInPlace": { "@type": "City", "name": "Berlin" }
  },
  "amenityFeature": [
    {
      "@type": "LocationFeatureSpecification",
      "name": "S-Bahn Prenzlauer Allee",
      "value": true,
      "description": "350m, approximately 4 minutes walk"
    },
    {
      "@type": "LocationFeatureSpecification",
      "name": "Grundschule am Kollwitzplatz",
      "value": true,
      "description": "600m, approximately 7 minutes walk"
    }
  ],
  "offers": {
    "@type": "Offer",
    "price": 1450,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

এই তালিকা এখন একটি সমাধানযোগ্য ভৌগোলিক সত্তা। এটি এলাকা, নৈকট্য, মূল্য সীমাবদ্ধতা এবং রুম গণনা দ্বারা প্রশ্নের জন্য পুনরুদ্ধার করা যায়। geo স্তর ছাড়া একটি তালিকা শুধুমাত্র পুনরুদ্ধার করা যায় যদি AI তার ঠিকানা স্ট্রিং প্রশ্নকৃত অবস্থানে ম্যাচ করার দুর্ঘটনা ঘটায়, যা অনির্ভরযোগ্য।

এজেন্ট AEO এবং পোর্টাল AEO এর মধ্যে পার্থক্য

ব্যক্তিগত এজেন্টরা AEO কাজ করছে একটি ভিন্ন সমস্যার সমাধান করছে: ব্র্যান্ড এবং কনটেন্ট দৃশ্যমানতা, পাড়া গাইড, FAQ কনটেন্ট। পোর্টাল অপারেটররা একটি স্কেল-এ ইনভেন্টরি সমস্যার সমাধান করছে। প্রতিটি তালিকা পৃষ্ঠার পৃষ্ঠা স্তরে এম্বেড করা নিজস্ব geo ডেটা প্রয়োজন। যা একটি সিস্টেমেটিক ডেটা পাইপলাইন প্রয়োজন, কনটেন্ট কৌশল নয়।

82% ভোক্তা এখন স্থানীয় এবং সম্পত্তি গবেষণার জন্য AI সরঞ্জাম ব্যবহার করে। শুধুমাত্র 1.2% স্থানীয় ব্যবসা AI সার্চ সুপারিশে প্রদর্শিত হয়। পোর্টালগুলি যা ফাঁক বন্ধ করবে সেগুলি হবে যারা প্রতিটি তালিকাকে একটি মেশিন-পাঠযোগ্য ভৌগোলিক প্রসঙ্গ সহ ডেটা সত্তা হিসাবে বিবেচনা করেছে, শুধুমাত্র একটি রাস্তার ঠিকানা সহ একটি কনটেন্ট পৃষ্ঠা নয়।