AI Citation Factors: তিনটি স্তর (Domain, Schema

AI সার্চ র্যাংকিংয়ের বেশিরভাগ গাইড দুটি স্তর কভার করে: domain authority এবং schema markup। সেই গাইডগুলি ভুল নয়, কিন্তু এগুলি এমনভাবে অসম্পূর্ণ যা বিশেষভাবে লিস্টিং পেজ, প্রপার্টি পোর্টাল, ভ্যাকেশন রেন্টাল প্ল্যাটফর্ম এবং যে কোনো সাইট যেখানে ইনভেন্টরি অবস্থান-ভিত্তিক সেগুলিকে ক্ষতি করে।

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

স্তর ১: Domain এবং Entity Authority

Domain authority হলো প্রবেশের প্রয়োজনীয়তা, র্যাংকিং সিগন্যাল নয়। এটিকে একটি থ্রেশহোল্ড হিসেবে মনে করুন। প্রায় DA 20 থেকে 30-এর নিচের domain থেকে পেজগুলি কন্টেন্টের মানের নির্বিশেষে প্রতিযোগিতামূলক প্রশ্নের জন্য AI উদ্ধৃতি পুলে খুব কমই দেখা যায়। সেই থ্রেশহোল্ডের উপরে, raw DA-এর উদ্ধৃতি ফ্রিকোয়েন্সির সাথে দুর্বলতর সম্পর্ক রয়েছে।

DA মেঝের উপরে প্রাথমিক সিগন্যাল হিসেবে যা প্রতিস্থাপিত হয়েছে তা হলো entity authority: AI মডেলগুলি কতটা স্পষ্টভাবে এবং ধারাবাহিকভাবে বোঝে আপনার সাইট কী, এটি কী কভার করে এবং কাকে পরিষেবা দেয়।

ওয়েব জুড়ে ধারাবাহিক entity পরিচয়। আপনার সংস্থার নাম, ঠিকানা, URL এবং বিভাগ আপনার নিজের সাইট schema, Google Business Profile, শিল্প ডিরেক্টরি এবং উদ্ধৃতি উৎস জুড়ে একইভাবে প্রদর্শিত হতে হবে। NAP অসংগতি সরাসরি আপনার entity পরিচয় খণ্ডিত করে একটি শক্তিশালীর পরিবর্তে একাধিক দুর্বল প্রতিনিধিত্বে।

বিষয়ভিত্তিক সংহতি। AI মডেলগুলি মূল্যায়ন করে আপনার সাইটে একটি স্পষ্ট, ধারাবাহিক টপিক ক্লাস্টার আছে কিনা। একটি সংকীর্ণ বিশেষ ক্ষেত্রে ৩০টি নিবন্ধ সহ একটি সাইট একই DA সহ ২০টি অসংযুক্ত বিষয়ে ছড়িয়ে থাকা সাইটের চেয়ে সেই বিষয়ে বেশি entity-authoritative।

sameAs রেফারেন্স। আপনার JSON-LD-তে sameAs প্রপার্টি আপনার entity-কে Wikidata, Crunchbase, LinkedIn এবং অন্যান্য authoritative গ্রাফে এর প্রতিনিধিত্বের সাথে লিঙ্ক করে। AI মডেলগুলি এগুলি ব্যবহার করে নিশ্চিত করতে যে তারা যে entity নিয়ে যুক্তি করছে তা একাধিক উৎস জুড়ে বর্ণিত একই entity। সম্পূর্ণ LocalBusiness JSON-LD বাস্তবায়ন গাইড এটি সঠিকভাবে কীভাবে কাঠামো করতে হয় তা কভার করে।

আপনার domain যদি DA মেঝে অতিক্রম করে, entity authority উন্নতি অতিরিক্ত লিঙ্ক-বিল্ডিংয়ের চেয়ে AI উদ্ধৃতির জন্য বেশি করবে।

স্তর ২: Schema Markup

Schema markup হলো আপনার পেজ এবং AI পুনরুদ্ধার সিস্টেমের মধ্যে যোগাযোগ স্তর। স্ট্রাকচার্ড ডেটা সহ পেজগুলি অপ্রকাশিত পেজের তুলনায় উল্লেখযোগ্যভাবে বেশি হারে উদ্ধৃত হয়। Google AI Overviews স্ট্রাকচার্ড ডেটা সহ পেজগুলিকে পছন্দ করে, এবং প্রতিযোগিতামূলক প্রশ্নের জন্য নির্বাচনের বৃদ্ধি উপাদানগত।

বেশিরভাগ বাস্তবায়ন Google-এর Rich Results Test সন্তুষ্ট করে এমন ফিল্ডগুলিতে থামে, যা AI উদ্ধৃতি সিস্টেম সন্তুষ্ট করার মতো নয়।

বেশিরভাগ বাস্তবায়ন যা সঠিকভাবে পায়: @type, name, description, url, openingHours, telephone, address, FAQ schema।

লিস্টিং পেজের জন্য বেশিরভাগ বাস্তবায়ন যা মিস করে: লিস্টিং ইনভেন্টরির জন্য ডিজাইন করা schema types-এ বেশিরভাগ গাইড যে types নিয়ে আলোচনা করে তার থেকে ভিন্ন প্রপার্টি প্রয়োজন।

রিয়েল এস্টেট, ভ্যাকেশন রেন্টাল এবং হসপিটালিটি লিস্টিং পেজের জন্য, প্রাসঙ্গিক types হলো RealEstateListing, LodgingBusiness, Hotel, VacationRental, Apartment এবং SingleFamilyResidence, প্রতিটি মূল্য নির্ধারণ এবং উপলব্ধতার জন্য Offer-এর সাথে নেস্টেড। এই types শুধুমাত্র সঠিক অবস্থান প্রপার্টির সাথে সংযুক্ত হলেই AI পুনরুদ্ধারের জন্য তাদের কাজ সম্পাদন করে।

FAQ Schema ভুল

FAQ schema সম্পাদকীয় কন্টেন্টের জন্য মূল্যবান। এটি AI ইঞ্জিনকে ঠিক বলে দেয় একটি কন্টেন্ট কোন প্রশ্নের উত্তর দেয়। লিস্টিং পেজ সম্পাদকীয় কন্টেন্ট নয়। একটি প্রপার্টি লিস্টিং ভ্যাকেশন রেন্টাল সম্পর্কে একটি সাধারণ প্রশ্নের উত্তর দিচ্ছে না। এটি একটি নির্দিষ্ট অবস্থানে একটি নির্দিষ্ট entity প্রতিনিধিত্ব করছে। FAQ schema একটি AI ইঞ্জিনকে সেই লিস্টিং "মেট্রোর কাছে ২-বেড অ্যাপার্টমেন্ট"-এর সাথে মেলাতে সাহায্য করে না। লিস্টিং পেজের জন্য সঠিক schema entity-relational, Q&A-আকৃতির নয়।

স্তর ৩: Geo Data (কম-ডকুমেন্টেড স্তর)

AI মডেলগুলি যেগুলি অবস্থান-নির্দিষ্ট প্রশ্নের উত্তর দেয় ("Yellowstone-এর কাছে ভ্যাকেশন রেন্টাল," "downtown থেকে ১০ মিনিটের মধ্যে অ্যাপার্টমেন্ট") তারা অন্তর্নিহিত ভূ-স্থানিক ম্যাচিং করছে। তারা প্রশ্ন করা অবস্থান এবং তাদের পুনরুদ্ধার পুলের entities-এর মধ্যে ভৌগোলিক সম্পর্ক সমাধান করছে। সেই ম্যাচিংয়ের জন্য কাজ করতে, আপনার লিস্টিং পেজগুলিকে স্ট্রাকচার্ড ডেটায় সেই সম্পর্কগুলি স্পষ্টভাবে এনকোড করতে হবে।

প্রতিটি লিস্টিং পেজে নির্ভুল GeoCoordinates

GeoCoordinates geo প্রপার্টি কমপক্ষে চারটি দশমিক স্থান সহ latitude এবং longitude সহ মৌলিক সিগন্যাল। এটি ছাড়া, AI ইঞ্জিনগুলি আপনার ঠিকানা স্ট্রিং geocode করে, যা যেকোনো অসংগতিতে ব্যর্থ হয় এবং অনেক কম নির্ভুলতা উৎপন্ন করে। বেশিরভাগ বাস্তবায়ন যেগুলি মোটেই geo অন্তর্ভুক্ত করে তা শুধুমাত্র একটি সাইট-স্তরের LocalBusiness schema-তে প্রয়োগ করে, পৃথক লিস্টিং পেজে নয়। প্রতিটি লিস্টিং পেজ তার নিজস্ব সমাধানযোগ্য ভৌগোলিক entity হতে হবে।

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 48.8566,
  "longitude": 2.3522
}

containedInPlace: প্রপার্টিকে ভৌগোলিক শ্রেণীবিন্যাসের সাথে লিঙ্ক করা

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

"containedInPlace": {
  "@type": "Place",
  "name": "Le Marais",
  "containedInPlace": {
    "@type": "City",
    "name": "Paris"
  }
}

কাছের Place Entities: ট্রানজিট, স্কুল, ল্যান্ডমার্ক

যখন একজন ব্যবহারকারী "মেট্রোর কাছে রেন্টাল" এর জন্য জিজ্ঞাসা করেন, AI প্রপার্টি এবং ট্রানজিট অবকাঠামোর মধ্যে স্পষ্ট মেশিন-পাঠযোগ্য সম্পর্ক খুঁজছে। আপনার বিবরণে "মেট্রো লাইন ৪ থেকে ৫ মিনিট হাঁটা" বলা একটি বাক্য AI পুনরুদ্ধারের জন্য কিছুই করে না। একই তথ্য amenityFeature-এর মাধ্যমে লিঙ্ক করা Place entity হিসেবে কাঠামোবদ্ধ হলে পুনরুদ্ধারযোগ্য।

কেন লিস্টিং ডেটাবেস স্বাভাবিকভাবে এই ডেটা বহন করে না

বেশিরভাগ প্রপার্টি ম্যানেজমেন্ট সিস্টেম এবং লিস্টিং ডেটাবেস অপারেটররা যা এন্টার করেন তা সংরক্ষণ করে: ঠিকানা, মূল্য, বেডরুম, বাথরুম, ফটো। এগুলি মানুষের জন্য একটি পোর্টাল ব্রাউজ করার জন্য তৈরি হয়েছিল, মেশিন-পাঠযোগ্য ভৌগোলিক প্রসঙ্গের জন্য নয়। একটি mapping API এই ব্যবধান পূরণ করে। Geocoding API ঠিকানাগুলিকে নির্ভুল কোঅর্ডিনেটে রূপান্তরিত করে। Points-of-interest API একটি নির্দিষ্ট ব্যাসার্ধের মধ্যে ট্রানজিট স্টপ, স্কুল, পার্ক এবং ল্যান্ডমার্ক ফেরত দেয়। আউটপুট schema.org types-এ সরাসরি ম্যাপ হয় এবং স্কেলে লিস্টিং পেজ JSON-LD-এ এমবেড করা যায়।

তিনটি ব্যবধান বন্ধ করা কেমন দেখায়

একটি লিস্টিং পেজ যা AI পুনরুদ্ধারে ভালো পারফর্ম করে:

১. ধারাবাহিক entity পরিচয়, sameAs রেফারেন্স এবং একটি স্পষ্ট বিষয়মূলক ক্লাস্টার সহ একটি domain-এ থাকে ২. মূল্য নির্ধারণের জন্য Offer-এর সাথে নেস্টেড সর্বাধিক নির্দিষ্ট প্রযোজ্য schema type ব্যবহার করে ৩. লিস্টিং পেজ নিজেই GeoCoordinates অন্তর্ভুক্ত করে, পাড়া এবং শহর entities-এর সাথে লিঙ্ক করার জন্য containedInPlace, এবং ট্রানজিট, স্কুল এবং ল্যান্ডমার্কের জন্য কাঠামোগত কাছের Place ডেটা

বেশিরভাগ লিস্টিং পেজ স্তর ১-এর অংশ এবং স্তর ২-এর মৌলিক অংশ কভার করে। প্রায় কেউই স্তর ৩ কভার করে না। যে পেজগুলি তিনটিই কভার করে সেগুলিই অবস্থান-নির্দিষ্ট প্রশ্নের AI উত্তরে দেখা যায়।

বর্তমানে মাত্র ১.২% স্থানীয় ব্যবসা AI সার্চ সুপারিশে দেখা যায়। তারা গড়ে সর্বোচ্চ domain authority সহ নয়। তারা তিনটি ব্যবধান বন্ধ করেছে।